- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Thu, 29 Sep 2011 20:28:16 -0400
- To: Gavin Carothers <gavin@topquadrant.com>
- CC: Mischa Tuffield <mischa.tuffield@garlik.com>, Arnaud Le Hors <lehors@us.ibm.com>, public-rdf-wg@w3.org
On 9/29/2011 6:06 PM, 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. In the world I live in (and this is potentially related to what you say below about graphs / datasets being baked into RDF Concepts), TriG is the default serialization, and we rarely deal with other media types. If we want to produce documents full of triples, we use TriG's default graph. > 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. The SPARQL spec isn't suggesting any semantics from these comments -- just informing the reader that the graphs from those turtle documents were included in the RDF dataset with those names. > 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> . > > >> @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. It feels weird to me as well. > 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). While this matches the world I live in (named graphs everywhere), I'd be (pleasantly) surprised if it's a viewpoint that flies with the broader community. Lee > > --Gavin > >
Received on Friday, 30 September 2011 00:28:59 UTC