Re: Service description open questions (was: Re: SPARQL TC today cancelled.)

On Feb 11, 2010, at 9:39 AM, Lee Feigenbaum wrote:

> Right now at http://kasei.us/2009/09/sparql/sd-example.ttl sd:NamedGraph is modeled as a wrapper around sd:Graph. Could sd:NamedGraph instead be a subclass of sd:Graph?

I don't think so. The problem with going that route is deciding where you attach the graph name. Right now the name is attached to the sd:NamedGraph along with the pointer to the actual sd:Graph. If a sd:NamedGraph were a subclass of sd:Graph, you'd have to attach the name directly to the graph. This might be problematic in cases where the graph has multiple names, or where a graph is available as both a named graph and a default graph, or where the graph description is available (via linked data) from somewhere else and you can't add your own (local) name to its description.


> At [1] you ask two questions:
> 
> """
> What is the rdf:type of the "available universe" node... The rdf:type might be something like sd:GraphCollection (being a collection of named graphs, but without a default graph it isn't a sd:Dataset).
> """
> 
> If we are sticking with the sd:availableGraphDescriptions property (rather than sd:availableGraphs), then I believe this class is better off as sd:GraphDescriptions or sd:GraphDescriptionCollection. Personally, I'd prefer that we drop the "description" bits, but I've never been a stickler for modeling.

OK. I'm happy to go with either of these. I'm ambivalent on dropping "description" if only because the description of the graph seems distinct from the actual graph. The thing we're pointing to is metadata about the graph, distinct from the graph itself which might return the RDF graph contents is dereferenced (not totally sure about the info/non-info resource issues here).


> """
> What is the property that connects this node with the available named graphs?... It's tempting to think that the property should be sd:namedGraph, already used in describing the default dataset, but then the domain of sd:namedGraph can't remain sd:Dataset. The GraphCollection essentially seems like an rdf:Bag, suggesting that the property might be a subproperty of rdfs:member.
> """
> 
> Can sd:Dataset be a subclass of sd:GraphCollection?
> 
> If an sd:GraphCollection is defined as an unordered collection of zero or more descriptions of graphs with names, then an sd:Dataset is a specific such collection that also defines a default graph. Is that ok? If so, we can reuse sd:namedGraph and have its domain be sd:GraphCollection (which then might be better renamed to sd:NamedGraphCollection or sd:NamedGraphDescriptions or sd:NamedGraphDescriptionCollection :-) )

Yes, this sounds right. sd:Dataset would then act like a sd:GraphCollection (or whatever we call it), but also allow a sd:defaultGraph property.


>> 2. Resolve name clashes
>> 
>> There's some confusing naming going on in the current draft of the SD
>> vocabulary, and I think it needs changing. Right now we have both an
>> sd:EntailmentRegime class and an sd:entailmentRegime property, and
>> depending on the work discussed above regarding datasets and graph
>> collections, we may be heading towards also having sd:NamedGraph and
>> sd:namedGraph. Anyone want to suggest better names so that the case
>> isn't the only distinguishing factor here?
> 
> I actually find this naming convention comforting, so I have no suggestions, but YMMV.

My impression was that the only-difference-in-case would be confusing for people, but I just ran across this same naming pattern in SCOVO. If nobody has a problem with this, I'm happy to leave it.


>> 3. Support for property functions
> 
> I've heard Leigh and Andy both make the argument that property functions are blessed by the existing specs, and I've never been that convinced myself. And even if the results are legal SPARQL results, the spec. does not define any concept such as property function, so it would be pretty difficult for the service description spec. to include a mechanism for defining them without explaining what they are. Since there's no existing specification scaffolding for SD to rely on here, it would need to invent it, and that seems way out of scope for the service description work. All of which leads me to conclude that we ought not to include this, and rather encourage the broader-than-the-Working-Group community to coalesce on a means of talking about property functions.

Andy and I talked a bit about this off-list, and I think I'm now less hesitant to include support for it. Andy pulled together a list of implementations that support property functions, and it was much more wide-spread that I had thought. Given the moderately wide support, I'm willing to add it to the SD vocab so long as we don't get dragged into trying to model all aspects of property functions and how they work. I'd defer to your judgement on "way out of scope," but if it were to go in, I'd imagine we could find a way to word it carefully and vaguely so that very little definition was actually required. Something like: "Claimed support for a property function indicates that the implementation may make use of custom code in matching any triple pattern that uses the property in the predicate position. The specific mechanism used to perform this matching is undefined."


>> 4. Add an sd:Language instance IRI for SPARQL Query 1.0.
> 
> Right now we define sd:SPARQLQuery, which is versionless. Should we instead define sd:SPARQL10Query and sd:SPARQL11Query? I'm not sure.

I'm not thrilled with how that looks, but it does seem to be the saner naming scheme.


>> 5. Add reference to voiD in the SD document.
> 
> Is there any questions for the group here?

No, but it had been brought up before, and I wanted to make sure it was written down somewhere.


>> 1. Leigh (again in [2]) had also requested that we consider a means
>> of annotating that an endpoint requires the explicit declaration of a
>> dataset. This could just be another IRI for use with sd:feature (as
>> we've already done with sd:DereferencesURIs and
>> sd:UnionDefaultGraph).
> 
> I think this would be a very useful feature annotation to include.

I can add this to the existing list of supported features. Any preference on what it should be named? sd:RequiresDataset?

>> 2. Sandro had briefly brought up (I think at the F2F2?) expressing
>> regex patterns for describing the "available universe" of graphs. I'm
>> not sure we've ever seriously discussed it, so would like to hear
>> people's thoughts on it.
> 
> I also think this is an important topic, but don't have a well-baked opinion on it -- I think it's very useful, since enumerating millions of graphs is not particularly practical. On the other hand, this relies on inventing some new machinery, which is always a bit scary to me.
> 
> Can we reuse anything from POWDER here?

I am very unfamiliar with POWDER (so someone more familiar with it may want to chime in), but I believe it does have terms for this sort of thing. In particular, the includeiripattern and includeregex terms seem relevant. Might be worth fleshing this out a bit, but I'm similarly worried that it's "inventing some new machinery" somewhat late in the game (even if it's just new machinery to hook up the SD vocab to existing POWDER stuff).

.greg

Received on Monday, 15 February 2010 23:21:25 UTC