Hi Frank I do not believe either of these are on the agenda for the current round of SPARQL standardization but it may be worth you suggesting these for inclusion as a Future Work item on the comments mailing list - [email protected] - so that they can be included on the list at http://www.w3.org/2009/sparql/wiki/Future_Work_Items and feed into any future SPARQL working group
FWIW there are already a number of interoperable implementations of the LARQ style syntax already out in the wild - my own dotNetRDF implements this as does Clark & Parsia's Stardog and possibly others I'm not aware of. Also property functions in general are widely implemented for a variety of purposes in a whole variety of triple stores and SPARQL engines. The slightly subversive property function syntax is slightly awkward and at odds with the pure SPARQL specification but it address the general limitation of extension functions in SPARQL that they can only return a single value and the 1.0 specific limitation that you could not actually bind the result of an extension function to a variable. Even with BIND in SPARQL 1.1 you can only assign a single value in a BIND so either you'd have to have multiple extension functions to get the matches and the scores (and then how do you relate them) Rob On Mar 9, 2012, at 11:44 AM, Frank Budinsky wrote: > > > Hi, > > I'm trying to get a handle on the strategic implications of using Jena > property functions, and specifically the LARQ textMatch property function > approach for supporting full text search. > > Does anybody know if there is anything in the works to try to include > property functions in a future version of SPARQL? I noticed a small amount > of discussion about this back in 2008, but haven't seen anything since. I > see that they are not part of the standard SPARQL 1.1 specification and > don't even appear to be an avenue of extension envisioned by the SPARQL 1.1 > specification, which envisions extension value functions and entailment > regimes. > > It seems that the syntax of property functions borrows the syntax of > legitimate SPARQL queries but gives it an implementation-specific meaning > that runs counter to SPARQL semantics. Has there been any attempt to > reconcile what property functions do with the semantics of SPARQL 1.1, as > described in chapter 18: > http://www.w3.org/TR/sparql11-query/#sparqlDefinition? > > Thanks, > Frank
