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

On 2/4/2010 4:39 PM, Gregory Williams wrote:
> On Feb 2, 2010, at 8:40 AM, Lee Feigenbaum wrote:
>
>> In the meantime, I'd like to ask our editors to repeat an exercise
>> from a couple of months ago - can you please send (either to the
>> list or to Axel and me) a prioritized list open issues for your
>> documents that need the group's attention?
>
> Here's a list of open issues for service descriptions (roughly
> prioritized):
>
> 1. Add missing classes and properties for named graphs and graph
> collections
>
> We've currently got a sd:Dataset for describing SPARQL datasets, but
> for completeness' sake we still need classes for describing a graph
> (sd:Graph would be the obvious name), a named graph (being a thing
> with both a name and a sd:Graph), and a collection of named graphs
> (to represent the "available universe" of graphs from which to
> construct a dataset; this class is the domain of
> sd:availableGraphDescriptions).
>
> I tried to start a discussion[1] last month on the "available
> universe" modeling, but didn't get very far with it. If anyone can
> help out with the modeling here, and especially with the relationship
> between the properties used for describing the "available universe"
> and the similar properties for describing a sd:Dataset, I'd really
> appreciate it.

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?

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.

"""
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 :-) )

> 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.

> 3. Support for property functions
>
> This was brought up by Leigh Dodds on the comments list (the most
> recent reply is at [2]), and it needs to be addressed. Leigh had
> asked for a way to describe the supported property functions of an
> endpoint in a similar way to how we already describe supported
> scalar/aggregate functions and entailment regimes. My expressed
> position was that these latter fell within the framework of SPARQL
> and existing specs while the former didn't. Leigh questioned my
> reasoning by claiming that property functions are "sanctioned by the
> spec" while the "union default graph" feature annotation (which we've
> already decided to support) isn't sanctioned by the spec. Given his
> response I'd like to hear from others in the WG on this issue.

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.

I also don't understand the comments about the union default graph -- 
this seems to me to be similar territory - it's clearly (to me) legal by 
the spec, though not spelled out and defined. The difference is that 
this is a "behavior in the wild" that is easily explained / defined in 
the service description specification, whereas property functions are not.

> 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.

> 5. Add reference to voiD in the SD document.

Is there any questions for the group here?

> In addition to these, there are a couple of things that have come up
> briefly in the past that I want to bring up and officially either
> pass on them or work on their inclusion in the SD doc:
>
> 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.

> 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?

Lee

>
> thanks, .greg
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0153.html
>
>
[2] 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Jan/0004.html
>
>
>

Received on Thursday, 11 February 2010 14:39:57 UTC