Re: Practical issues arising from the "null relative URIs"-hack

On Thu, Mar 27, 2014 at 9:50 PM, henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

>
> On 27 Mar 2014, at 15:08, Reto Gmür <reto@wymiwyg.com> wrote:
>
>
>> >> I think Henry makes a good case that the use of relative IRIs is the
>> Right Thing here. It's practical, it has precedent with the way HTML works,
>> it's webby, and it's supported by the relevant RFCs.
>> >
>> > Ok, let's look into this:
>> > - "practical": it requires hack on the client (throwaway URI to
>> serialize against) and prevents framework to be effectively used on the
>> server side. As for expressiveness it allows less flexibility (creating
>> multiple resources in one post) as Antoine's proposal
>>
>> It works just fine, without hacks, if client and server use RDF libraries
>> that support relative IRIs.
>>
>
> But not when using tools which act on the RDF data model level.
>
> What LDP does is like if I ask people calling me to use SIP with H.264 as
> codec omitting the domain of the target. Something you can do with the
> right (hacker) library but certainly not with a normal phone.
>
>
>> > - "it has precedent": I don't know of any protocol which requires the
>> sender to send URIs that are relative to something that isn't defined yet.
>> So I don't know where the precedent is.
>>
>> There are protocols (WebDAV, APP) where messages with relative IRIs can
>> be POSTed and it works just as expected.
>>
>
> Neither in WebDAV nor in APP I see where the client is required to send
> post IRIs relative to a yet undefined base (i.e. that the client couldn't
> also send as absolute URI). In Antoine's proposal you can use relative URIs
> but you don't have to.
>
>
> If you consider RFC5995 ( Using POST to Add Members to WebDAV )
> http://tools.ietf.org/html/rfc5995
> you need only consider that it does not say anything about relative URIs
> to understand
> that because it says nothing it does exactly what we are proposing. If you
> were to use
> a RFC5995 compliant server to POST some Turtle with relative URIs in it,
> then you'd
> get exactly the LDP intended result. A turtle document that was posted
> with a <> URI would refer
> to the document created.
>
Granted. The same happens if you send an email with text/turtle
content-type. Still, a bit far fetched to see this use as the intended
design or even as to see  an established design pattern in that, imho.


> An HTML document that was posted with a link <a href="">this doc</a>
> would refer to the document created.  All of this just falls out
> naturally, out of concepts of
> relative URLs and the act of creating a new resource for which the URL is
> not known in
> advance, and which it is the responsibility of the server to create.
>
Typically this is only used for fragment identifier, which have special
mention in RFC398.


>
>
>
>>
>> > - "supported by the relevant RFCs": The RFC says the sender is
>> responsible that the base URI can be established, this seems quite
>> different from "the receiver defines a base URI" to me.And I haven't got an
>> answer to
>> http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0033.html yet.
>>
>> If the protocol implemented by the server asserts that the server will
>> choose an appropriate base IRI, then a client has met its responsibility by
>> using that protocol.
>>
>
> It that is enough to satisfy the requirement I don't see how the earlier
> requirement "the base URI is defined by the context of the application"
> without also satisfying the requirement that the client is responsible. I
> think your interpretation of the requirement makes it pointless.
>
>
> You have to read carefully:
> "the clieet is responsible that the base URI can be established"
>
> The client is responsible to figure out what?
>   A: that the base URI _CAN_ be established.
>
> It is NOT responsible
>   B:  that the base URI BE established
>

If I wanted to do a similar literal analysis I could point out that the
client is responsible that _THE_ base URI can be established and not just
that _A_ base can be established. The definite article "the" denotes a
thing "already mentioned or assumed to be common knowledge" (according to
oxford dictionaries). Therefore the article cannot refer to something that
has not yet even been defined.

But even clearer is the situation if we consider it from the perspective of
relevance theory. Like I don't tell you "make sure to take the right bus"
if there is only one bus serving the bus stop we can safely assume that the
RFC authors don't tell us "the client is responsible that a base uri can be
establieshed" if clients have no way to fail to do so.

Cheers,
Reto


>
> Those are two very different statements. The LDP spec says what an LDPC
> is. A client will know that
> if a resource is an LDP then that resource WILL be able to establish the
> base URI. If a client knows that
> a resource is an LDPC then it will have established that that resource CAN
> establish the base URI
> even though the client still does not know what the base URI will be at
> the point of posting.
>
>
>
>> >> Given all this, it appears to me that using relative IRIs to good
>> effect in LDP is a step in the right direction.
>> >
>> > Well the goal of LDP is not to establish faits accomplis to push the
>> RDF specification to adopt new features but in my understanding to apply
>> the existing standards where possible. As for this use case there are
>> alternatives that do not go beyond the current standard and they do not
>> provide any disadvantage (except if you need the dirt) I don't think we
>> should go beyond the existing standard.
>>
>> As you have seen in this thread, one can argue in either direction by
>> pointing to existing standards.
>>
>> It comes down to a question whether you prefer to do the Right Thing
>> vis-a-vis RDF Concepts or vis-a-vis RFCs 2616 and 3986.
>>
>
> You are arguing that it doesn't violate RFC3986 where I disagree, I didn't
> read any argument that any of the two RFCs you mention would suggest that
> the base URI should not be the resource against which the request is sent
> (as with Antoine's proposal) but that the base should be the resource the
> server has yet to create.
>
> Cheers,
> Reto
>
>
> Social Web Architect
> http://bblfish.net/
>
>