Re: Namespace of builtin functions

Eric Prud'hommeaux wrote:
> Oops, just found this in my pending mbox:
> 
> 2006-06-13T14:06:08Z <LeeF> could someone scratch out the current
> proposal, please?
> 
> AndyS has provided a list of URIs. As a staring point, consider the
> following fairly conservative scenario:
> 
>   we (continue to) use XPath functions by name and (continue to) not
>   say what the behavoir of the fn:matches is when encountered in a
>   tripple pattern or a FILTER.

I agree about in triple patterns.

I don't see the harm in saying that all SPARQL functions translate to function 
calls in expressions in the SPARQL function syntax.

FILTER regex(...) is the same as FILTER fn:matches(...)

If an implementation wants to handle only the fixed functions, then that 
implementation could even directly place the alternative forms in it's parser 
and not see the alternative forms anywhere else.

> 
>   we provide a namespace sop: and use it in the spec like so:
>     Operator  Argument type   Function	      Result type
>     BOUND(A)  variable	      sop:isBound(A)  xsd:boolean

I have a minor quibble about the "op" in "sop".  If possible, can we avoid the 
fn/op split and have only functions?

> 
>   In 11.3 Operator Mapping [MAP], we add
>     [[
>     The name of each SPARL operator may be concatonated onto the
>     namespace <mumble> to provide an identifier for the semantics of
>     that operator. The behavoir of such a URI in a triple pattern
>       _:a sop:logical-or _:b
>     or a FILTER
>       FILTER (sop:logical-or(?a, ?b)
>     is not defined.*
>     ]]
> .

Let's not define any relationship between function IRIs and properties.

Logical-or and logical-and don't translate to pure functional forms because of 
the handling of errors in shortcut evaluation - that is, can't evaluate all 
the arguments then evaluate the logical function (errors aren't values because 
it would violate the signatures of op/fn that don't accept errors - they can 
be implemented as such).  Conservatively, these two logicals should be avoided 
as IRIs.

> 
> * We could probably define the meaning of these URIs in FILTERs
>   without much controversy, but we would add various error situations
>   regarding the cardinality and argument types that the grammar would
>   not be able to detect. I believe this would just make implementation
>   and validation more difficult; it would make the language bigger
>   without giving any new utility to the user. My weasel wording above
>   is intended to be equivilent to what Howard pointed out in F&O:
> [[
> Functions defined with the op prefix are described here to underpin
> the definitions of the operators in [XML Path Language (XPath) 2.0],
> [XQuery 1.0: An XML Query Language] and [XSL Transformations (XSLT)
> Version 2.0]. These functions are not available directly to users, and
> there is no requirement that implementations should actually provide
> these functions.
> ]]
> 
> Re: defining URIs for XPath operators, I note that we do not intend
> any special semantics for evaluation in the SPARQL context; in fact,
> they are called after the transformation from RDF terms into XSD
> terms.  That said, I also don't know what we get out of it. With the
> above scenario, we aren't defining terms that anyone will every be
> able to utter in an interoperable manner. Implementations can just
> make up whatever identifiers they want for these operators. Does the
> glue code that SteveH and AndyS are writing need to interoperate?

My specific requirement is uniformity within an implementation, not 
interoperability.  I have code that groks expressions and being able to treat 
all expressions as functions made it easier.

Defining IRIs for things then seemed like a "good thing" to do.

	Andy

> 
> 
> [MAP] http://www.w3.org/2001/sw/DataAccess/rq23/#OperatorMapping
> 
> 
> On Fri, Jun 09, 2006 at 02:00:57PM +0100, Seaborne, Andy wrote:
>> Attached is a proposal for URIs for functions in SPARQL.
>>
>> Also includes is a list of all the op: and fn: operators/functions rq23 
>> mentions.  I produced that list of F&O qnames used with:
>>
>> while(<>)
>> {
>>     @a = /((?:op:|fn:)[\w-]+)/g ;
>>     next if ( $#a < 0 ) ;
>>     print join("\n", @a), "\n" ;
>> }
>>
>> which I haven't exhaustively checked.
>>
>> 	Andy
>>
>> Dan Connolly wrote:
>>> On Tue, 2006-06-06 at 16:56 +0100, Seaborne, Andy wrote:
>>>> Dan Connolly wrote:
>>>>> On Tue, 2006-06-06 at 09:54 +0100, Seaborne, Andy wrote:
>>>>> [...]
>>>>>> so that makes fn:compare:
>>>>>>
>>>>>> http://www.w3.org/2005/xpath-functionscompare
>>>>>>
>>>>>> Ugh.
>>>>> I don't think so.
>>>>>
>>>>> I think their rule for making URIs for functions gives:
>>>>>  http://www.w3.org/2005/xpath-functions#compare
>>>>>
>>>>> see http://www.w3.org/Bugs/Public/show_bug.cgi?id=3121 , which
>>>>> is a bug reported by me about the namespace document not agreeing
>>>>> with the spec, where Norm confirms that
>>>>> the full URI for fn:starts-with is
>>>>> http://www.w3.org/2005/xpath-functions#starts-with
>>>>>
>>>>>
>>>> Dan,
>>>>
>>>> Thanks for the correction - it's good to know there is a suitable URI. 
>>>> Reading the namespace document
>>> The namespace document is acknowledged to be buggy. See above.
>>>
>>>> in the CR version it is:
>>>>
>>>> http://www.w3.org/2005/xpath-functions/#name
>>>>
>>>> for all op: and fn: operations.
>>>>
>>>> If we follow the same route, we'd get something like:
>>>>
>>>> http://www.w3.org/2006/sparql-functions/#datatype
>>> I advise against that last /
>>>
>>>> and put a namespace document at http://www.w3.org/2006/sparql-functions
>>>>
>>>> EricP - can we automatically generate the namespace doc from rq23?
>>>>
>>>> 	Andy
>>>>
>>>>

Received on Monday, 19 June 2006 16:42:42 UTC