Re: Comments on LDP TR http://www.w3.org/TR/2013/WD-ldp-20130730/

Continuing on from Page 9

4.5.7   MUST not SHOULD.

4.6.2  Another totally grey area.  When you DELTE a resource, the server may or may not remove triples with that subject from other resources.  (When  you delete R, any quad R P O R2) may be deleted.
This is ripe for a profile, and in that profile the value of what happens must be explained.
E.G. when you delete R  then R is removed from any containers, so there is no  C member R 
*on this server* or on some other URI region.
 This is  hairy feature, as of course, as it can't apply to triples stored on another server, so
people splitting data across different servers will get unexpected results.
This sounds like another protocol which needs a lot more thought.
For now, suggest the LDP spec doe snot specify such behaviour, maybe flag magic triple side effects as possible extension spec in future.

4.8 PATCH is optional.  Sugget a MUST. PATCH is to first order the only thing LDP provides over WebDav.

4.8.2 MUST

Suggest specify a the subset of sparql-update we use at the moment as  a mandatory patch format to get basic interop, with  possible later extension to other languages.


*******

Something I mentioned in a mail  a long time ago is the necessity of doing 
atomic flag (P/V) operations with a PATCH.

To recap, you have to be able to do a form of DELETE triple(s) which will FAIL
and prevent any corresponding INSERT from happening.  This is top be 
able to allocate shared resources.

Eg     DELETE   { :x :nextID 4 }  INSERT DATA { ?x :nexID 5 }.

Hmm.   Maybe this is covered by the ETag system sufficiently.
If so, the case should be given as an worked example and put in as a test case.
A collaborative system which allows atomic flag setting is fundamentally more valuable
than one which doesn't.


******* 

4.9.1 Servers must support the OPTIONS method.  Why?   Should there be  a basic level
of functionality which any LDPR allows and which does not require OPTIONS polling?

OPTIONS is expensive: another round trip.

Always avoid an extra round trip if you can.
We need this system to move really fast.
Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users.

Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension
or a POWDER label say).    You have to do it for every fresh URI you find.

The Linked Data operation is a GET.  Is the basic operation for an LDP-capable client always OPTIONS, GET,  or GET, OPTIONS? 

Maybe key headers can be put into the HEAD and GET response.

Maybe the class of resource announced with Link: rel=type
can have a URI which can be looked up itself and cached.
and will give the set of features in a standard way.

Suggest define  a core LDP protocol which does NOT use OPTIONS, by assuming that 
the core functionality is enough for clients to do what they need.
Clients needing extensions maybe can use OPTIONS.  But maybe POWDERR should be preferred.


4.10.1 
"The triples in the representation of the each page are typically a subset of the triples in the resource - same subject, predicate and object."  Same triples then? eh?  


I prefer the word "inspect" for the way "introspect" is used in the document.
"Introspection" is normally looking into oneself, not into something else.


4.10.2.1  "Conservative clients" again.  Explain the value of doing this or not doing it.


4.10.2.2  Servers MAY do it.  That means clients MUST handle it.

4.10.2.3.  MUST

#########################
4.10.2.3   303 lis a basically very unsatisfactory design because of the round trip.  As this is a new spec, suggest defined 20X code meaning like a 303 but containing the representation of the thing 303d to.  This has been found to a problem in LD. LDP can avoid it now.
Benefit: First page back to user in one less round trip.
#########################


4.10.2.4.3   This design puts the type and next links in the data.  I prefer I think using HTTP headers here as elsewhere.  Page control stuff is very meta, messy to have it in with actual data.
Not a problem for containers, but for normal LDPRs IMHO.


4.11.1   "LDP does not provide clients with any way to detect whether or not the server is capable of inlining (all its resources or any specific resource), nor does it provide clients with any way to influence which (if any) resources are inlined in any given response."    This implies cleints must all be able to handle inlining and recover from it if they didn't really want it.

Need to define a protocol here properly or abandon the feature.

(N3 or one of its weak imitations is obviously a clear choice for a inlined data, as it allows you to preserve the provenance, and basically explain which triples are from which resource.  I understand this would frighten people at this stage.)


How does a client find the non-member-property version of a resource R?


(Done to  page 15)

Tim






On 2013-08 -22, at 08:27, Tim Berners-Lee wrote:

> Hi,
> 
> I've been reading the LDP last call draft,
> http://www.w3.org/TR/2013/WD-ldp-20130730/
> 
> (Note that I am reviewing this as a developer, not as W3C Director,
> though I may be a developer who has a shrewd idea of the sort of
> things the Director might approve of.)
> 
> I have comments at various levels.   Two things concern me mainly,
> firstly that the LDP platform will support the functionality
> which the RWW community has been using, including tabulator-based 
> apps, and the second if that the platform in general provide a 
> in interoperable functionality between compliant client and server.
> 
> This last is threatened mainly by the huge number of SHOULD's 
> for the server where I would have expected MUSTs to get 
> interoperability, and a persistent theme throughout the spec
> the actual behavior a client or a server can expect of the other party
> relies completely on out-of-band agreements.
> To the extent that that is true, the document does not define an interoperable system.
> 
> I'll go though in document order now.
> 
> 4.1 "burden of constraints for resource creation"  - I feel that phrase needs more explanation
> 
> 4.2.9  This is an example of a complete interop gap.   The server might or might not mess with your triples in any way defined elsewhere. 
> I suggest defining a clean simple high-interop version of the server in which the server doesn't mess with or constrain the client application at all.  This is a really important use case.  For the RWW world, LDP storage must be generic storage which be used with any app.   Maybe we can make a profile of this spec for this case, with no domain knowledge or behavior in the server.  If not, we have a problem.
> 
> 4.2.10  "Conservative clients"?? you already have MUST and MAY, but now (and elsewhere) you have conservative (and presumably liberal) clients.    If you want to create a new conformance class Conservative Client, by all means do so, but declare it in the Conformance section and SAY WHAT YOU GET from each level of conformance.    A client is not an animal tiptoeing gingerly or not into the wide world out there, it is a small hard part of a machine which either works or doesn't work.  The phase occurs elsewhere too.  It is a red flag. (Why would a client want to be conservative? What is risked by not being?  What would a liberal client do? Does this mean the server needs to be more specified to eliminate the risk)
> 
> I would strongly support as an exercise looking at a version of the spec with everything which is not mandatory removed, and see what you end up being able to do with it.
> 
> 4.3.4.  Broken.  No guarantee that anything will work. Suggest strongly the following:-
> 
> LDP Clients MUST either give no accept header or must give a header which includes 
> at least text/turtle and has NO OTHER mime type with a higher  q.
> 
> LDP servers, which a GET is received on a LDPR, if text/turtle is present and there is no other mime type with a higher q, they MUST return turtle.  If there is no Accept header, they must return turtle.
> 
> Protocol value: If a LDP client goes a GET it will get the data in turtle.  Interop is achieved.
> 
> This provides interoperability and also is compatible with HTTP.
> It allows existing conneg software to be used, and allows LDP to work within a general conneg-based server serving other things too.
> 
> 
> 4.5.6.  You allow servers which do not support PUT or PATCH or POST.  Why?   A client using such a server will have no write  ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET.  Suggest change all to MUST, or make two levels of server,  one which supports PUT and PATCH and no collections, and one which supports everything.
> 
> 4.5.2  Same sort of problem.  Are you preventing data loss or not?  Suggest yes. Clients MUST use If-match and Servers MUST implement it (which may men ignoring it in a case where you know nothing else can change the data).   Protocol value: Changes from others are never overwritten.
> 
> 4.5.4  A server which throws out random triples is hard as a basis for RWW applications.  We must have a profile in which the server has no domain knowledge.
> 
> 4.5.6 MUST allow PUT.  Otherwise, what is the point?  
> 
> (Note that for clients which use PUT To make resources in system that looks like a unix file system, servers will have to generate intermediate directories.
> It is very useful for servers to be able to map a unix-like file system, for many reasons, including the isomorphisms between remote and local storage.  So the use case in which the LDP server is a big unix file system but with PATCH as a performance enhancement is important.  This doesn't affect the spec in any normative way I can see.)
> 
> In this case, objects are not made by POST to a collection, but being mentioned in a a new file with PUT and then later PATCH.
> 
> Those are comments on the first 9 pages.  I have marked up the other  24 pages as well, and the type of remark is fairly similar.  I'll send these now.
> 
> Keep up the good work
> 
> Tim BL
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>