BTW, I am also not thrilled about the term MagicProperty, and I had thought long about how to name them in SPIN. I went for spin:MagicProperty because they are really declared as rdf:Properties as well. The term “property function” is IMHO confusing because it overlaps with the term “function”, which means something similar but for FILTER and project statements. It is not a good idea to have two identifiers for distinct things, and one identifier is a sub string of the other…

Thanks for the clarification! There seems to be no phrase to describe this feature that everyone is happy with. So far we have:

* Magic Predicates
* Magic Properties
* Property Functions
* Functional Predicates

I don’t really like the “Magic” ones, and have tended to prefer property functions. I’ve been using “Functional Predicates” lately as I picked up the term from Lee Feigenbaum, but clearly its got some additional connotations that are confusing. Perhaps “property functions” is a less confusing term.

Nice post! Just one small terminology comment: I wouldn’t qualify list:member as a functional predicate (which implies that for one subject, there is just one object).

I would qualify list:member as a non-deterministic (one subject, N possible objects) builtin (the engine knows how to derive truth values for it) predicate.

Cheers!
y

You’re correct I should have looked more closely at SPIN after you had pointed it out to me, as it does have vocabulary that addresses similar use cases.

Looking at the documentation I can see that it defines classes for both extension functions (ScalarFunctions in the SPARQL 1.1. parlance) and magic properties (what I’ve called FunctionalPredicates).

And your examples do encourage people to attach labels and comments to function descriptions, which is one of the key things I want to achieve.

It was totally obvious to me that SPIN could be used in this way based on my earlier, and less in depth looks at the specifications.

So yes, SPIN could very much be used to achieve what I’m suggesting here, so apologies for lack of reference.

Having said that there’s a couple of areas where my draft vocabulary includes some extra constructs.

Firstly, I’ve defined the notion of a FunctionLibrary. Is this something that SPIN supports?

Secondly, I’ve added some terms to describe a SPARQL processor, and relate it to the functions it implements. As far as I can see SPIN doesn’t do that, as a SPIN function definition is basically a description of how an engine could/should implement a function, not whether it supports it. I think there’s a subtle difference there? Would be interested in your thoughts.

Finally, I’ve also tried to define my terms and extra properties so that it aligns with the SPARQL 1.1 terminology. Clearly you couldn’t have done this as SPIN was developed first! One reason for doing that is to ensure things relate sensibly, and I’m sure SPIN could be tweaked to do the same.

But, to be honest, I’d be more than happy if the SPARQL Working Group decided, or could be convinced, to slightly extend the scope of the Service Description specification to include a little more information. Illustrating the small amount of extra vocabulary required is one useful way to do that I think. And this is another reason for my attempting this.

I’d be more than happy for another, more standard or well-supported vocabulary to get widely used. The key thing is to get people documenting that extensions!

Thanks again for your comments.

This post was mentioned on Twitter by ldodds: New blog post: Describing SPARQL Extension Functions http://is.gd/4O5pz #rdf #sparql #vocampdc…

http://www.spinrdf.org/spin.html#spin-functions

and

http://composing-the-semantic-web.blogspot.com/2009/01/understanding-spin-functions.html

This vocabulary not only covers things like rdfs:comment about the function, but also details about the function’s arguments. Furthermore, SPIN function declarations can include a body declaration that points to executable code, including another SPARQL query and JavaScript code.

I am not quite sure why you do not even reference this related work, even though I have pointed you at this in my previous comments on the blog? What is wrong with the spinrdf vocabulary for your use case?