- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 19 Jun 2006 17:42:19 +0100
- To: Eric Prud'hommeaux <eric@w3.org>
- CC: dawg mailing list <public-rdf-dawg@w3.org>
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