Re: Named Graph Serialisation

Peter,

Notation3 (n3) is the extension of basic RDF for very much that  
purpose, where an RDF graph itself can be a node in a graph, using  
{braces}. Like:

:reading1  cal:date "2007-09-12T05:70:00";
	ex:readings {   :water temp  23;  :presure 1.006.   air temp 22.1;  
pressre 1.007 }.
:reading2  cal:date "2007-09-12T05:70:00";
	ex:readings {   :water temp  23.4;  :presure 1.006.   air temp 22.1;  
pressre 1.007 }.
:reading3  cal:date "2007-09-12T05:70:00";
	ex:readings {   :water temp  23.2;  :presure 1.006.   air temp 22.1;  
pressre 1.023 }.
:reading4  cal:date "2007-09-12T05:70:00";
	ex:readings {   :water temp  23.;  :presure 1.006.   air temp 22.1;  
pressre 1.007 }.
:reading5  cal:date "2007-09-12T05:70:00";
	ex:readings {   :water temp  23;  :presure 1.006.   air temp 22.1;  
pressre 1.004 }.

You can use rules (eg N3 rules) to pull out things in flat plain RDF.

The notation above avoids the repetition of the graph ID on every quad.
(N3 also avoids repetition of subject as well.)

http://www.w3.org/DesignIssues/Notation3

Tim

This can be serialized into a graph, by n3 reification into triples,  
but as you say it is impractically verbose and unreadable.

On 2007-07 -25, at 11:49, P.L.Coetzee wrote:

>
> Dear all,
>
> I have a fairly large set of data persisted in a quad-store,  
> consisting of a set of named graphs within a single dataset. Other  
> than TRiX, I've yet to come across any 'accepted' means of  
> seralising the graphs into a single RDF dump (ideally which could  
> be read in without massive memory overhead, such as can be easily  
> done with N-Triples).
>
> The obvious solution to me would be a sort of 'N-Quadruples',  
> whereby one serialises the Graph URI as the first element per line,  
> followed by the usual S-P-O triple pattern of N-Triples. This seems  
> like the simplest solution (in terms of ease of implementation,  
> readability, as well as for any future processing on the set). What  
> are the list's thoughts on such an approach; is there any prior art  
> that I'm missing, other standards that can achieve the same goals  
> that etc?
>
> Thanks in advance for your thoughts!
>
> Cheers,
> Peter
>

Received on Thursday, 26 July 2007 11:09:48 UTC