ldp-ISSUE-54 (NullURIReplacement): Which URIs should replace null relative URIs provided in LDPR representations? [Linked Data Platform core]

ldp-ISSUE-54 (NullURIReplacement): Which URIs should replace null relative URIs provided in LDPR representations? [Linked Data Platform core]

http://www.w3.org/2012/ldp/track/issues/54

Raised by: David Wood
On product: Linked Data Platform core

This issue was raised by James Leigh on the public-ldp mailing list:

http://www.w3.org/TR/2013/WD-ldp-20130307/#http-post-1 says:
        5.4.8 In RDF representations, LDPC servers must interpret the
        null relative URI for the subject of triples in the LDPR
        representation in the request entity body as referring to the
        entity in the request body. Commonly, that entity is the model
        for the “to be created” LDPR, so triples whose subject is the
        null relative URI will usually result in triples in the created
        resource whose subject is the created resource.

According to the above the term <> in turtle should be replaced with the
to-be-created URI. However, the term <#adr> would still be resolved
against the base URI of the document (either in the @base directive,
Content-Location, or the request-uri). This will be hard to implement as
most Turtle parsers do not expose the relative lexical term used in the
document, but often only the absolute URI.

In Callimachus we experimented with overriding the base URI while
parsing, but that proved problematic as many turtle writers don't allow
explicit term representations and it prevented the use of general
purpose entity handling (on either client or server). In the end we
realized that by overriding the base URI we were essentially /forking/
Turtle and only parsers/writers that were aware of this could be trusted
preserve the null relative URI.

Callimachus now requires the client to create a URI and use it in the
RDF document. However, the server may end up substituting the primary
URI with a canonical variant. I suggest the LDP spec adopt a similar
approach.

Received on Friday, 15 March 2013 13:55:26 UTC