Re: Named Graph Serialisation (add to publishing linked data document?)

Chris i think this issue is VERY important for publishing linked data
in general.

Would it make sense that you add a chapter to your publishing linked
data document called "providing a dump" and list these alternatives?
(and others that might come?)
If it does, please do :-)

i think spiders can then find out by themselves what format it is.. as
long as there is somehow a list of those "generally recognized"

thanks
Giovanni


On 7/26/07, Chris Bizer <chris@bizer.de> wrote:
>
>
> Hi Peter,
>
> there is also TriG. See http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/
>
> TriG is a plain text format for serializing Named Graphs and RDF Datasets.
> The TriG syntax offers a compact and readable alternative to the XML-based
> TriX syntax.
> TriG is roughly Turtle, extended with
>
>   a.. '{' and '}' to group triples into multiple graphs and
>   b.. to precede named graphs by their names
>   c.. optional :- graph naming operator
> TriG is implemented by NG4J which works together with Jena and by Sesame. So
> you can use the syntax together with both frameworks.
>
> Cheers
>
> Chris
>
>
> --
> Chris Bizer
> Freie Universität Berlin
> +49 30 838 54057
> chris@bizer.de
> www.bizer.de
> ----- Original Message -----
> From: "P.L.Coetzee" <P.L.Coetzee@open.ac.uk>
> To: <semantic-web@w3.org>
> Sent: Wednesday, July 25, 2007 5:49 PM
> Subject: Named Graph Serialisation
>
>
>
> 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 10:43:57 UTC