RE: service description vocabulary



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Steve Harris
> Sent: 26 September 2009 09:36
> To: public-rdf-dawg@w3.org Group
> Subject: Re: service description vocabulary
> 
....

> > Strictly speaking, isn't the default graph also a named graph (since
> > it generally also have its own URI).
> 
> I don't believe so, from ยง8 of SPARQL 1.0:

Agreed.

> 
> "A SPARQL query is executed against an RDF Dataset which represents a
> collection of graphs. An RDF Dataset comprises one graph, the default
> graph, which does not have a name, and zero or more named graphs,
> where each named graph is identified by an IRI."
> 
> I do this the area of default / named graphs in the SPARQL spec could
> do with some clarification, as I've not yet met two SPARQL
> implementers who agree on the meaning or intention.

Default graphs in ARQ may or may not have a name as well.  Both setups are possible and occur.  There was an intent in the 1.0 spec to allow both cases and there are use cases for other, as there are for default being the RDF merge of all named graphs or the manifests of the named graphs or something else.

> > So
> >
> > <endpoint> sd:datasetDescription [
> >  sd:defaultGraph [
> >                sd:graphName <graph-name> ;
> >   sd:graphDescription <void-dataset-for-default-graph> ;
> >        ] .
> >  sd:namedGraph [
> >   sd:graphName <graph-name> ;
> >   sd:graphDescription <void-dataset-for-named-graph> ;
> >  ] .
> > ] .
> 
> Let's not bake Void into SPARQL. It's sufficient to say that it should
> be an RDF description, the exact vocabulary can be left open.

Agreed.  Getting the mechanism right is really important.  The vocabularies will evolve although voiD is a current good 

We need a way to describe graphs, not just datasets, but that might be a matter of description not a vocabulary defined by the WG.  The boundary of mechanism and vocabulary is not so clear cut here but a starting point, can be assume that the datasets description should describe the graphs if makes sense for a particular dataset.  What I'm looking for is a reason to includes it in the datasetDescription range and, at the moment, I don't see one.

We could propose a little vocabulary like the one above - but change the prefix from sd: to soethign else for :defaultGraph and :namedGraph.  But, this would be a vocabulary to succeed based on usage not a spec'ed mechanism.

> 
> > while I'd think a simple way would be
> >
> > <endpoint> sd:datasetDescription <void-dataset-for-dataset> ;
> >  sd:defaultGraph <graph-name> ;
> >  sd:namedGraph <graph-name> .
> 
> That would be more palatable, but if it's possible for the client to
> request a description there needs to be some way for the client to
> request the description of a specific graph.

Putting in dataset structural description into voiD(++) and querying that would be better as it allows the query to pull in a wide variety of RDF information.  If we pull up this one part into service description graph but the rest of the description of the dataset is in another place, it could be a bit messy.

 Andy


> 
> >> Additionally, I was hoping to get feedback on whether people think
> >> the vocab should distinguish between language extensions and
> >> supported features? Is this a meaningful distinction? For example,
> >> an extension that modifies the SPARQL syntax (e.g. to support the
> >> BINDINGS keyword) versus a feature describing the algorithm used to
> >> generate DESCRIBE results. The former clearly extends SPARQL, but
> >> the latter works within the existing constraints of SPARQL. Thoughts?
> 
> I don't think it's necessary to distinguish explicitly.
> 
> I would imagine that the client has some concept of the features it
> can make use of. Others it has no use for, whether their inside or
> outside the SPARQL spec are probably not relevant.
> 
> An exception would be something that tried to gather generic
> information about SPARQL endpoints (a catalogue of endpoints or so),
> but that's a bit of a corner case, and I doubt it make much difference
> anyway.
> 
> - Steve
> 
> --
> Steve Harris
> Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
> +44(0)20 8973 2465  http://www.garlik.com/

> Registered in England and Wales 535 7233 VAT # 849 0517 11
> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10
> 9AD

Received on Monday, 28 September 2009 13:44:22 UTC