Re: SPARQL TC today cancelled.

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.

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?

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.

4. Add an sd:Language instance IRI for SPARQL Query 1.0.

5. Add reference to voiD in the SD document.


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

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.


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, 4 February 2010 21:39:57 UTC