On 9 Oct 2013, at 12:46, Barry Norton <[email protected]> wrote:
> > > > On Wed, Oct 9, 2013 at 12:15 PM, Hugh Glaser <[email protected]> wrote: > [...] > > So having a separation between SPARQL Service Description and voiD would just > be plain wrong. > They must embrace each other, so that consumers can easily work out how to > use what they think of as a "dataset". > > I would also add that if I take a REST-like view of the world, which I do for > accessing a SPARQL endpoint (I am simply retrieving a document), the > distinction between dataset and service becomes very blurred. > Even calling it a "SPARQL Service Description" seems rather old-fashioned to > me. > > Hugh, I tend to agree (certainly about calling them 'service descriptions', > ugh). From a REST point of view, void:Datasets, named graphs (capable of > RESTful interaction via Graph Store Protocol) and SPARQL query/update > 'endpoints' (ugh again) are all resources that allow one to find other, more > specific, resources. > > That said if we accept that one needs some up-front guidance on what those > resources allow you to get to (a big 'if', if the REST community, but I don't > think anyone in ours would be happy with just a media type) then we want them > to be self-describing in RDF. Always & everything! > At the same time, the relationships we want to attach to the query/update > endpoints are semi-distinct, no? You'd agree these are different classes of > resource? Yes, or perhaps I am saying different sub-classes? Thinking of it that way, I then look at Frans' list of the kind of thing he would like to be able to say about endpoints. It seems that at least the following might be common to almost any delivery mechanism for datasets: • The time period of the next scheduled downtime • (the URI of) a document that contains a human readable SLA or fair use policy for the service • URIs of mirrors So, yes, there are semi-distinctions, but if that implies semi-non-distinctions, there should be very useful mileage in trying to make such things deeply compatible. Or at least starting from there? Best Hugh > > Barry
