W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: [TTL] Standardizing N-Triples

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sat, 02 Apr 2011 16:31:16 +0100
Message-ID: <4D974144.90000@epimorphics.com>
To: Steve Harris <steve.harris@garlik.com>
CC: nathan@webr3.org, Eric Prud'hommeaux <eric@w3.org>, Alex Hall <alexhall@revelytix.com>, Richard Cyganiak <richard@cyganiak.de>, RDF-WG <public-rdf-wg@w3.org>

On 02/04/11 01:34, Steve Harris wrote:
> On 2011-04-01, at 21:39, Nathan wrote:
>> Eric Prud'hommeaux wrote:
>>> * Alex Hall<alexhall@revelytix.com>  [2011-04-01 15:29-0400]
>>>> On Fri, Apr 1, 2011 at 3:21 PM, Nathan<nathan@webr3.org>  wrote:
>>>>> Andy Seaborne wrote:
>>>>>> On 01/04/11 20:06, Nathan wrote:
>>>>>>> Andy Seaborne wrote:
>>>>>>>> Are there examples of real worlds data that uses relative IRIs in
>>>>>>>> N-triples? If not, we could decide that theer is no base processing in
>>>>>>>> RDF-triples, absolute IRIs only.
>>>>>>> How can we have @base processing if there are no directives or @base
>>>>>>> definitions? I'd strongly suggest we keep this to *IRI*s only.
>>>>>> The base is also set by where the file is read from.
>>>>> Indeed, reliably though? for instance taking in to account the file being
>>>>> sent by email, being part of a zip archive, being in the message body of a
>>>>> PUT HTTP request, being in the body of a GET HTTP response with a
>>>>> Content-Location which differs from the effective request URI?
>>>>> Personally, I'd quite like that can of worms left closed for RDF-Triples :)
>>>> +1, but that reflects my bias as a developer, where often times all I'm
>>>> handed is an input stream with no information about where the content came
>>>> from.  It's nice to be able to use that information when it's available, but
>>>> I think it's extra complexity that's best left out of a simple format like
>>>> N-Triples.
>>> I'm a big fan of relocatable data and often take advantage of the
>>> ability to have a set of interrelated resources which can be moved
>>> from one location to another, or accessed both via e.g. http: and
>>> file: protocols. As an example, the SPARQL test suite manifests have
>>> relative references to the data, queries and expected results. This
>>> allows me to run the tests off the web or to download a tarball to an
>>> arbitrary location and run the tests. Relative references are a very
>>> handy element of web architecture.
>>> I expect that, if we demand absolute IRIs, folks will get around it
>>> with sed scripts and the like, but it will be an unnecessary pain.
>> A very good point Eric, personally I hadn't came across this with N-Triples yet due to my own use-cases so far, although I guess in hindsight I can see uses for relative IRIs here too..
>> Jury's out for me on this one I'm afraid, can't weigh up the cost / possible ambiguity of relative IRIs vs having a simple unambiguous format.
>> Saying that.. I think we can reasonably expect people only to use relative IRIs on the web, and not come crying because they've used them in a base-less environment..!
> Most (all?) of the other RDF syntaxes already allow for relative IRIs, so it doesn't add any new requirement to a system that can already handle RDF.
> I agree with Eric that it's useful, I'm not sure whether there will be systems that only consume NTriples though.

The relative IRI thing can be achieved by using and serving up Turtle. 
We could therefore keep N-triples with a design centered on a dump 
format, and sticking to only absolute IRIs makes sense there to "freeze" 
the data.

Turtle would be the usual format, N-Triples a subsidiary format, with 
the RDF specs (primer) in Turtle and just mentioning N-Triples is passing.

I'd expect people to author in Turtle.


> - Steve
Received on Saturday, 2 April 2011 15:31:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC