[Versa] Issue 100A proposal, extension functions

[Uche Ogbuji]

On Sat, 2005-09-03 at 15:48 -0400, Chimezie Ogbuji wrote:
> On 8/29/05, Michael Olson <Mike.Olson at fourthought.com> wrote:
> > 
> > 
> > I would like to propose adding a section 7.7 to the specification.
> > This section would discuss function names.  We would also change the
> > "identifier" production in the EBNF for a function-call to match a xml
> > qname production.  function names without a prefix would be assumed to
> > be in the "versa core function" namespace.  All other namespace must
> > have been registered with the implementation yada yada yada.
> 
> I plan on finishing up this section with the following requirements
> for resolving function references:
> 
> The default namespace for function name resolution is:
> http://rdfinference.org/versa/0/2/
> 
> (should this change since we no longer own that domain?)

Yahoo was running a $5 domain sale, so I grabbed rdfversa.org.  Each
person can only grab 1 domain at that price, so I didn't also get
rdfversa.info.

Anyway, we can probably switch to

http://rdfversa.org/ns/2/0/


> It is automatically bound to the 'versa' prefix.  The core functions
> are defined in this namespace.  If a function is referenced with a
> namespace outside of the query processor is required to do the
> following:
> 
> First check if the namespace is bound in the current context (defined
> in a prefix declaration).  If it isn't, raise an error complaining
> about the unbound namespace prefix reference.  If it is, check if any
> function with the matching namespace and name are registered with the
> query processor.  If so, invoke the function with the appropriate
> arguments.  If there is no matching function, convert each argument to
> a resource (following the conversion rules - a little trickier if the
> argument is a literal) and return the objects of all statements where
> the subject is any of the arguments (converted to resources) and the
> predicate is identified by the URI of the function name.  I.e.,:
> 
> 
> ns:functionName(res)  :=   resource - ns:functionName -> *
> 
> (where ns:functionName is not registered with the implementation)
> 
> If there are no arguments, raise an exception stating that the

I would avoid "raise an exception" terminology: too language specific.
Better to sat "It is an error if...".


> referenced function is not registered with the implementation.  I
> think this is more useful than simply complaining if the function
> isn't registered, and allows the use of functions as First Order
> Predicate mappings.  These can be overridden by registered extension
> functions.  In this way, you can allow certain  'high-level' semantics
> to be provided by extension functions that override certain predicates
> (in the same way that CWM uses predicates in the log namespace --
> http://www.w3.org/2000/10/swap/log.n3 -- to perform high level RDF
> management).
> 
> Beyond this, it is completely up to the implementation to determine
> how extension functions are registered.

The general idea is sound.


-- 
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html
Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/
Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html