- From: Sandro Hawke <sandro@w3.org>
- Date: Sun, 07 Jul 2013 12:51:19 -0400
- To: public-rdf-wg@w3.org
On 07/07/2013 08:48 AM, Markus Lanthaler wrote:
> On Sunday, July 07, 2013 1:35 PM, Sandro Hawke wrote:
>> It's not that the name doesn't denote the graph, it's that it doesn't
>> *necessarily* denote the graph. Eric's example will work fine in a
>> context where suitable dataset semantics are in use.
> Right. It is exactly that ambiguity that worries me.
>
>
>> Earlier, I gave the
>> example that this could be flagged by having the triple { <> a
>> rdf:BoundDataset } in the default graph. Another name for that might be
>> "Direct".
> A more granular alternative would be to define rdf:Graph which could be used
> to type things as "denoting graph name".
Yes, but that would require a whole lot of extra triples, for ever and
ever. My guess is we'll converge on the Direct+Webview semantics below,
and at some point it'll be flagged at some protocol layer so the dataset
wont even need to be flagged internally. At that point, it'll be as if
we'd been able to properly address it all now.
>
>> In contrast, we might also have a WebCacheDataset, or WebViewDataset, or
>> GraphStoreSnapshot, in which the graph names denote g-boxes whose
>> contents are the associated graphs. (Change-over-time here is a problem,
>> but it's the same problem we have throughout the RDF world.)
>>
>> Now that we have blank node graph names available, I'm thinking the most
>> popular dataset semantics will be a combination: for URLs, the
>> graph-name denotes the g-box; for blank nodes, the graph-name denotes
>> the graph.
> +1, yet we make it more complicated than necessary to express those
> semantics IMO
>
>
>> I'm not sure which way to treat genids - it depends if we
>> want the genid-creator to be obligated/encouraged to publish the graph
>> at the genid URL.
>>
>> But this is too speculative to put into a document that's slated to
>> become a REC by the end of the year. So instead, dataset semantics are
>> an extensibility point, and we can experiment for a while.
> ... probably leading to interoperability problems till we feel ready to make
> a decision at which point it probably is too late as we can't modify the
> semantics of existing data anymore.
>
> Sorry for being so negative but I think we are making a huge mistake here.
I agree it's a very uncomfortable, unfortunate situation. I think
there's a plausible path (outlined above) to a world where this is all
okay. Our current LC drafts keep us on that path, while giving us some
flexibility to switch to other paths if this turns out to have a problem.
What would you propose we do today, instead?
-- Sandro
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
Received on Sunday, 7 July 2013 16:51:33 UTC