W3C home > Mailing lists > Public > public-ldp-wg@w3.org > October 2012

Re: Linked Data Platform ISSUE-20: What is the base URI of a POSTed document?

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 11 Oct 2012 16:09:57 +0200
Cc: Alexandre Bertails <bertails@w3.org>, public-ldp-wg <public-ldp-wg@w3.org>
Message-Id: <2500FAD5-8D28-42D2-BBBC-ED883E4EB391@bblfish.net>
To: Andy Seaborne <andy.seaborne@epimorphics.com>

On 11 Oct 2012, at 15:54, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:

> 
> 
> On 11/10/12 13:57, Alexandre Bertails wrote:
>> On 10/11/2012 08:15 AM, Andy Seaborne wrote:
>>> 
>>> 
>>> On 11/10/12 12:56, Henry Story wrote:
>>>> What are these violations of the URI spec?
>>>> RFC3986 permits relative URLs ( in section 42 no less;-)
>>> 
>>> Section 5.1.3 defines how the base URI is determined - it's not an
>>> arbitrary choice.  RDF does not allow relative URIs.
>>> 
>>> http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
>>> 
>>> The complete solution is POST to container, get back a Location:, maybe
>>> a 301 (Moved Permanently), and PUT or POST to the location.  But it's a
>>> round trip and (arguably) an impractical nuisance.
>> 
>> This is pretty far from what people do out there with Web APIs...
> 
> Agreed - it's just an example that works without the base URI problem - so does SteveB's use of a bNode (except it describes "one of more" but that is minor).
> 
>> I believe that it's easy to solve: don't say that you POST an RDF
>> graph, just call it *relative* RDF Graph. In practice, the Container
>> knows what will be the final URL for the document, so it will be able
>> to resolve the URIs.
> 
> Agree and disagree.  There is no such thing as a "relative RDF Graph" and you can't now take an off-the-shelf triple store as backing the LDP.  I think it is a serious limitation if you can't take off-the-shelf-software, as it serious hinders take-up.  Others may prefer to have customized software specific to the purpose, based on efficiency and convenience.
> 
>>> If you want to use N-triples (no base URI), and the subject is the BPR,
>>> then you have to know the BPR URI before creating the N-Triples.
>> 
>> No, this is just wrong: you want to be able to define the graph
>> without knowing where it will live beforehand.
> 
> 
> Yes - you want to  define the graph without knowing where it will live beforehand. - in N-Triples, how would you do that?
> 
> A BPR is statements about a subject and (4.1.2) the subject of the statements is typically the BPR itself.
> 
> So if you want to POST to a container to create a new BPR with certain statements (one or more), you need to know the URI of the BPR to create the statements before you POST.
> 
> We have discussed the trick of using <> in Turtle.
> 
> In N-Triples, there is no such trick.  All syntax URIs are absolute.

No, all serialisation - except NTriples - have relative URIs:
 Turtle, RDF/XML, N3, and I am sure Json-ld too.

There is no trouble posting an NTriples document: you'll just find it difficult 
to refer to the non known resource ahead of time.

In any case we decided in favour of Turtle which does have them, and the other
option would not have been NTriples, but RDF/XML and perhaps JSON-ld.

You are confusing the syntax, with the semantics of the graph. 
You need absolute URIs for reasoning as I explained previously because you
do not want to have to rely on context. That is what URIs permit us to do.

But here we are speaking about the creation of resources, not reasoning with
resources. We are working on the HTTP POST method and serialisations that
later take context into account.

> 
> Therefore to send to an unknown place you must have the URI to construct the N-Triples.  But you don't know the URI.  oops!
> 
> (and Slug: is suggested, not required, and of course there are clashes and auto-increment to be considered).
> 
> 	Andy
> 
>> 
>> Alexandre.
>> 
>>> 
>>>     Andy
>>> 
>>> 
>> 

Social Web Architect
http://bblfish.net/



Received on Thursday, 11 October 2012 14:10:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:41 UTC