Re: Web Semantics for Datasets

On 7 Oct 2011, at 14:12, Peter Frederick Patel-Schneider wrote:
> For all HTTP clients?  Over all time?  For all
> hardware/software/protocol/internet errors?  
> 
> Without knowing the boundaries of the "every" the proposal is
> incomplete.

On 7 Oct 2011, at 13:48, Andy Seaborne wrote:
> I like something like this as a pattern of good practice (well, 2 patterns).  I don't agree with forcing the 4th column to have a specific meaning given all the other deployed uses we have now collected.

What Peter and Andy said.

This is good advice for deploying things, and very useful as a high-level architecture that helps with thinking about how the web of data works (in a similar vein as REST – it's not a specification, but a high-level architecture that more or less describes what's going on in practice).

This might be an additional (non-normative) document that this WG should perhaps write. If not, then at least the Primer should be informed by this.

But the normative definition of an RDF dataset (or whatever we end up calling it) should not rely on dereferencing. It should simply be an abstract data structure – just like RDF graphs – that can serve as a *building block* for things like you describe.

The way I see it, the proposal is backwards. We want to specify an abstract, idealised information space – a collection of RDF graphs. How to access that information space (dereferencing, SPARQL, N-Quads dumps, etc) is an implementation detail that's subject to pragmatic decision, unreliable networks, fads and fashions, and so on. When specifying the abstract information space, you cannot define it in terms of its access implementation. Just define the abstract information space, and leave it to the market to decide on how to access it.

The relationship between <u,G> in a named graph shouldn't be “dereferencing u yields G”. It should be “owner of u gets to say what's in G”, which already *is* the case per AWWW, so we don't actually need to say anything about that when specifying <u,G>.

Best,
Richard

Received on Friday, 7 October 2011 13:58:24 UTC