Re: Turtle support for Multiple Graphs, suggestion

On Apr 1, 2011, at 14:15, Richard Cyganiak wrote:

> On 1 Apr 2011, at 23:07, David Wood wrote:
>> The WG has expressed an interest in changing Turtle very, very little.
> 
> Right.
> 
>> That alone makes this proposal interesting enough to discuss.
> 
> I conclude the opposite!
> 
> Turning Turtle from a single-graph triple format to a multi-graph quad format is a *much* bigger change than any syntactic tweaks or extensions.

The Charter says:

"Standardize the Turtle RDF Syntax (see the Workshop result page for further references). Either that syntax or a related syntax should also support multiple graphs and graph stores (see work item listed below). This work should take into account the 14 January 2008 Turtle Syntax document, N3, TriG, and the SPARQL Query Language syntax."

We as a WG have not yet concluded whether there should be "that syntax or a related syntax".


Regards,
Dave


> 
> A fundamental change to the underlying data model of the existing media types (Turtle, RDF/XML) means that the changes won't be limited to the parser, but entire APIs and storage engines have to be rebuilt, not to mention the hairy webarch implications around authoritativeness.
> 
> I strongly believe that all quad/multigraph formats should get new, fresh media types.
> 
> (Maybe I'm just mishearing what you said Dave. My point is that once we add "@graph" or "<...> { ... }" or any other form of multi-graph support, we should no longer talk of making changes to Turtle, but we are making a new format. If there's any doubt about that, then it's important to raise a new ISSUE for this.)
> 
> Best,
> Richard
> 
> 
>> 
>> Regards,
>> Dave
>> 
>> 
>> 
>> 
>> On Apr 1, 2011, at 13:19, Nathan wrote:
>> 
>>> Hi Lee,
>>> 
>>> Nothing I guess, other than lending to a single, simple, coherent specification and single format which supports virtually all use-cases needed.
>>> 
>>> That said, I also see many benefits in keeping two distinct formats (such as TriG and Turtle), since I /really really really/ don't want to be following my nose around the web to documents containing quads or multiple graphs, and perhaps selfishly, don't really want the pain that will induce in API land.
>>> 
>>> So, although I suggested it and would maintain that it may well be easier for newcomers to understand than TriG or N-Quads, I really don't like the idea of having a single format myself :D and see anything Quad or Multiple Graph as being related to data store synchronization and data dumps, rather than to RDF.
>>> 
>>> Best,
>>> 
>>> Nathan
>>> 
>>> Lee Feigenbaum wrote:
>>>> Hi Nathan,
>>>> What would be the benefit of inventing something like this compared to using TriG which is similar in spirit and already in (some) use?
>>>> Lee
>>>> On 4/1/2011 12:10 PM, Nathan wrote:
>>>>> Hi All,
>>>>> 
>>>>> Just a quick, mini proposal wrt supporting multiple "named graphs" in
>>>>> turtle.
>>>>> 
>>>>> We could add a new keyword and directive, @graph (or @namespace), who's
>>>>> value was an IRI. This would be a minimal change to the grammar, for
>>>>> example:
>>>>> 
>>>>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>>>> @prefix dc: <http://purl.org/dc/elements/1.1/> .
>>>>> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>>>>> 
>>>>> # default graph
>>>>> <http://example.org/bob> dc:publisher "Bob" .
>>>>> <http://example.org/alice> dc:publisher "Alice" .
>>>>> 
>>>>> @graph <http://example.org/bob> .
>>>>> _:a foaf:name "Bob" .
>>>>> _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
>>>>> 
>>>>> @graph <http://example.org/alice> .
>>>>> _:a foaf:name "Alice" .
>>>>> _:a foaf:mbox <mailto:alice@work.example.org> .
>>>>> 
>>>>> I believe it's pretty self explanatory, so will spare getting in to any
>>>>> heavy details, other than a couple of basic questions:
>>>>> 
>>>>> - What would the scope of @prefix and @base declarations be?
>>>>> (either no change / file wide, or with a scope of the nearest "@graph")
>>>>> 
>>>>> - Would the value be an IRI, or an absolute-IRI?
>>>>> (my own preference would be the latter).
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Nathan
>>>>> 
>>>>> 
>>> 
>>> 
>> 
>> 
>

Received on Friday, 1 April 2011 18:32:49 UTC