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

On March 31, 2014 6:19:01 PM EDT, "Martynas Jusevičius" 
<martynas@graphity.org> wrote:
>> There's nothing in the spec that's designed for Turtle.    We're well
>aware
>> of other RDF syntaxes, including RDF/XML and JSON-LD.    The fact
>that you
>> can't access all LDP features from N-Triples and N-Quads does not
>seem to me
>> to be a serious problem.
>
>Sandro, all the proponents of the relative-URI proposal have come from
>the WG, but in public comments the opinions are not quite unanimous.
>What about the completely real possibility that the WG takes the wrong
>choice here -- is that not a serious problem?

That's an interesting question.   Bit of a long answer here.

I suppose it depends what you mean by wrong choice.    Every design 
decision involves some risk, since one never knows all the details about 
all the options.  The W3C process helps reduce and limit those risks, 
but nothing can eliminate them.

I'd say the process is pretty good at making sure the negatives about an 
option are understood, as there are many rounds of everyone looking at 
one chosen design, including Last Call (where we are now) and Candidate 
Recommendation (where we go next, with people implementing it).  The 
process is not as good at making sure there's no better option, though. 
  The usual assumption is that all the good options are known early in 
the process; if one is discovered late, it might not be adopted, since 
there isn't time for full review.  If one isn't discovered at all, of 
course it can't be adopted.

In this case, I think the risks were pretty well understood, and the 
options pretty well examined back when the WG made this decision, a long 
time ago now.   In the current discussion they're becoming even better 
understood.  And I'm still not seeing another option that's 
significantly better.

Also, I think the risks are quite bounded, because this design is 
attached to the current three LDP containers.   That is, this decision 
only applies if you're dealing with one of three particular classes of 
resource (ldp:BasicContainer, ldp:DirectContainer, and 
ldp:IndirectContainer).  Personally, frankly, I expect 5 years from now 
all three of those containers will be considered obsolete.   We're 
really just starting to figure out LDP, and my sense is several details 
of how those containers are defined will be problematic, once we have 
some more experience.   But for now, they're good enough to move forward 
a bit, and as we learn more we can define new and better ones.

If it turns out these POST semantics are bad, the newer, better 
containers can use different POST semantics.    So, that's the limit to 
the damage.   Also, one could extend the protocol later, even for these 
containers, to provide different post semantics.    For example, a 
server could include a Link header saying some other option is 
available, and the client could use an Expect: header to make use of it. 
  For example, the server could include: Link 
rel=placeholder-iri-for-self-reference 
<some-iri-that-would-never-occur-naturally) and then clients could use 
that instead of a relative graph.

So, I think even the worst case scenario, where using relative graphs 
turns out to be completely unworkable, wouldn't be that bad.

Also, I think it's unlikely to be completely unworkable.  The negatives 
I see are:

- confusion, since "relative graphs" are slightly different than what's 
in normal RDF.   Hopefully this discussion will lead to editorial 
revision of the spec to make this more clear.

- lack of support in RDF software.   I'm thinking RDF toolkits will pick 
up relative graphs pretty quickly, but I could be wrong.  During 
candidate recommendation we'll be specifically looking for evidence 
either way on this.  So we'll know a lot more before we move forward.

- lack of ability to make relative URI references based on the container 
URI.   This is a matter of message size, which I don't think is very 
important at this scale.

- lack of ability to use RDF syntaxes that don't allows relative IRIs 
when posting RDF content with metadata.    This doesn't seem like a big 
problem to me.   I can't see why someone couldn't switch from n-triples 
to turtle.

Am I missing anything in this analysis?

   -- Sandro


>Martynas
>graphityhq.com

Received on Tuesday, 1 April 2014 12:20:07 UTC