Describing the Structure of RDF Terms

By Lee Feigenbaum on March 24, 2011 10:20 AM | 1 Comment

I'm wondering if there are existing vocabularies and best practices that deal with the following use case:

How do I write down metadata about the return type of a SPARQL function that returns a URI?

Since "returns a URI" can be a bit ambiguous in the face of things like xsd:anyURI typed literals, we can be a bit more precise:

How do I write down metadata about the return type of a SPARQL function that returns a term for which the isURI function returns true?

Functions like this have all sorts of uses. We use them all the time in conjunction with CONSTRUCT queries and the SPARQL 1.1 BIND clause to generate URIs for new resources.

So, when describing this function, how do I write down the return type of one of these URI-generating functions? I want to write something like:

fn:GenerateURI fn:returns ??

If I had a function that returned an integer, I'd expect to be able to write something like:

fn:Floor fn:returns xsd:integer

But in that case, I'm taking advantage of the fact that datatyped literals denote themselves. (Thanks to Andy Seaborne for pointing this out to me.) I can't say this:

fn:GenerateURI fn:returns xsd:anyURI

This seems to tell me that my function returns something that denotes a URI. (One such things that denotes a URI is an xsd:anyURI literal.) But, again, that's not what I want to say here. I want to say that my function returns something that is syntactically a URI. That is, it returns something that is named by a URI. I considerd something like:

fn:GenerateURI fn:returns rdfs:Resource

But rdfs:Resource is a class of everything, and as far as I can tell would mean that my function could return a URI, a literal, or a blank node.

So any suggestions for how to approach this sort of modeling of the return type (and parameter types) for SPARQL functions?

Categories:

1 Comment

Ivan Herman | March 25, 2011 5:55 AM

I am not an OWL guru, so my understanding and/or encoding might be wrong, better check it... And, as always, it is not overly simple. And (surprise, surprise...) blank notes make this more complicated:-)

First case is if we ignore the blank node issue. I think that the definition of the following OWL class:



x:URI owl:equivalentClass [ owl:complementOf rdfs:Datatype ] .

defines a class whose individuals are either blank nodes or resources the way you want them. You can then use x:URI as a range for fn:returns.

But we do have blank nodes... thankfully, there is a POWDER specification that introduces a bridge between URI-s as strings and URI-s as resources: wsdr:matchesregex (see section 4.3 of the POWDER formal semantics: http://www.w3.org/TR/powder-formal/#regexSemantics). So the following:



x:URI owl:equivalentClass [

  owl:intersectionOf (

    [ a owl:Restriction ;

      owl:onProperty wsdr:matchesregex ;

      owl:hasValue "REGEXFORALLURIS" .

    ]

   [ a owl:Class; owl:complementOf rdfs:Datatype ]

  )

]

Where REGEXFORALLURIS is the regular expression for URI-s in general, it is in one of the RFC-s.

I actually wonder whether the intersection is necessary in the OWL sense, and whether you can do more simply

x:URI owl:equivalentClass [ a owl:Restriction ;
      owl:onProperty wsdr:matchesregex ;
      owl:hasValue "REGEXFORALLURIS" .
    ] .


I may be completely wrong. But it may help...

Cheers

Ivan