W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

RE: service description vocabulary

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 29 Sep 2009 13:24:06 +0000
To: Gregory Williams <greg@evilfunhouse.com>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3693EA8D903@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Gregory Williams
> Sent: 29 September 2009 02:42
> To: public-rdf-dawg@w3.org Group
> Subject: Re: service description vocabulary
> On Sep 28, 2009, at 12:16 PM, Gregory Williams wrote:
> >> Let's not fixate on Void. If Void is not sufficient then the
> >> community will come up with something more comprehensive.
> >
> > Well, I'm torn between saying "yes, absolutely," and thinking that
> > there are people (like the voiD folks) that are working on
> > describing RDF graphs, but that the SPARQL dataset case is specific
> > enough to SPARQL that maybe we should be providing the handful of
> > properties to allow leveraging graph description vocabularies in the
> > context of SPARQL datasets.
> After talking a bit with Andy on irc earlier, and hearing some good
> suggestions, I'd like to know what people think of the following
> compromise. The service description spec will simple have a
> sd:datasetDescription property (and an equivalent property for
> pointing to a dereferenceable URL for the same data)
> that will point
> to some sort of description of the dataset (with the specifics being
> left to others to sort out). Subsequently, a WG or IG note can be
> published minting new properties if necessary (such as ex:defaultGraph
> and ex:namedGraph) and detailing how a vocabulary like voiD can be
> used to describe a SPARQL dataset.

(not related service description particularly)

This has been a curiosity to me before:

If we have:

# Graph at URL <G>
<x> :pointsTo <y> .

Then we can have an ingraph reference

<#z> :data "foo" . 

where with <y> is <G#z> or <#z>.

Or we can have <y> be, for example, <http://elsewhere/abc> and by looking at the URI you can tell whether it's same-graph data or needs deferencing c.f. rdfs:seeAlso.

Or to put it another way - when is it good modelling to have different properties for the remote reference and local data and when is it good modelling to use the URI structure to notice "same place" data?


Received on Tuesday, 29 September 2009 13:25:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC