Re: On Graphis in Turtle (was Re: today's minutes available)

On 29/09/11 23:06, Gavin Carothers wrote:
> On Thu, Sep 29, 2011 at 6:41 AM, Mischa Tuffield
> <mischa.tuffield@garlik.com>  wrote:
>> Hello Again,
>>
>> On 28 Sep 2011, at 23:45, Arnaud Le Hors wrote:
>>
>> Hi all,
>> I was on a cellphone driving and it was too noisy for me to voice my
>> opinion then but I meant to say that, regarding the Graphs in Turtle
>> question, I find the @graph proposal more appealing than the {} one. I
>> think it is more consistent with what we already have in Turtle.
>>
>> It might sound silly but on a practical level I also find it convenient to
>> be able to add an @graph statement in my existing document without having
>> to re-indent all the following lines the way I would with the {} proposal.
>> I know that's not necessarily a high priority criteria but at the same
>> time Turtle was invented to make it easy for humans to write and read rdf
>> so I'd argue it's not totally off base either.
>>
>> Personally, I would rather not invent new things, and stick with one of the
>> existing quad based serialisations, i.e. TriG or N-Quads.
>
> I too would rather not invent new things. But to me claiming Turtle as
> the new default seralization for RDF and then saying "Well, it can't
> talk about the other new thing in RDF, named graphs" isn't really a
> good idea. In other words I don't think that having to change media
> types to name a graph is a good way forward.
>
> If we look at the example datasets from SPARQL:
>
> http://www.w3.org/TR/rdf-sparql-query/#exampleDatasets
>
> # Default graph
> @prefix dc:<http://purl.org/dc/elements/1.1/>  .
>
> <http://example.org/bob>     dc:publisher  "Bob" .
> <http://example.org/alice>   dc:publisher  "Alice" .
>
> # Named graph: http://example.org/bob
> @prefix foaf:<http://xmlns.com/foaf/0.1/>  .
>
> _:a foaf:name "Bob" .
> _:a foaf:mbox<mailto:bob@oldcorp.example.org>  .
>
> # Named graph: http://example.org/alice
> @prefix foaf:<http://xmlns.com/foaf/0.1/>  .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox<mailto:alice@work.example.org>  .
>
> We see comments being used to name graphs. Amusingly (and slightly
> horribly) this is the exact solution that TopBraid Composer uses as
> well. Turtle files have a comment added at the start of them to set
> the URI that TopBraid will refer to them by. The @graph keyword added
> to Turtle results in:
>
> # Default graph
> @prefix dc:<http://purl.org/dc/elements/1.1/>  .
>
> <http://example.org/bob>     dc:publisher  "Bob" .
> <http://example.org/alice>   dc:publisher  "Alice" .
>
> @graph<http://example.org/bob>  .
> @prefix foaf:<http://xmlns.com/foaf/0.1/>  .
>
> _:a foaf:name "Bob" .
> _:a foaf:mbox<mailto:bob@oldcorp.example.org>  .
>
> @graph<http://example.org/alice>  .
> @prefix foaf:<http://xmlns.com/foaf/0.1/>  .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox<mailto:alice@work.example.org>  .

Cough -- you have mangled the example.  It's three separate boxes in the 
SPARQL spec.  There is no implication of being in the same document.

>> @graph, would imply that you could have a document with loads of triples to
>> start with (seemingly Turtle) and then you would all of a sudden come across
>> an "@graph<http://foo.example/>" like statement, and you would suddenly
>> have to start parsing quads, this makes me feel slightly uncomfortable.
> If in RDF Concepts we are creating named graphs and datasets, then
> named graphs and datasets are no longer a bolt on attachment to RDF.
> They become much more intregul to RDF. The "you would suddenly have to
> start parsing quads" argument loses a great deal of weight, your RDF
> application likely already has to think about Quads (or whatever we
> call them in the abstract syntax).

When reading the @graph syntax suggests to me that it is one overall 
graph with subgraphs of the overall graph being named.

The TriG syntax puts the sets of triples in different units.

We either keep the graph as the primary unit of the semantic - RDF 
datasets are secondary (e.g. entailment is across a graph), or we'll 
need to rebuild the stack.

The closure argument, to have a thing that can talk about itself, 
suggests to me the use of graph literals where you can, to some degree, 
talk about another graph (the caveat is two fold: while it is a 
perfectly good mechanism, it's low level, needing vocabulary on top for 
even common usages; secondly, you still can't directly talk about the 
interaction of reading a graph document, only what you read; and third, 
(of two!) equality results in XMLLiteral like costs/confusion).

	Andy

>
> --Gavin
>

Received on Friday, 30 September 2011 08:39:15 UTC