W3C home > Mailing lists > Public > public-ldp-comments@w3.org > November 2013

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

From: <lehors@us.ibm.com>
Date: Sat, 16 Nov 2013 00:59:16 +0000
Message-Id: <E1VhUEG-00022L-Lh@jessica.w3.org>
To: Tim Berners-Lee <timbl@w3.org>
Cc: public-ldp-comments@w3.org,Read-Write-Web <public-rww@w3.org>, Tabulator Developers <tabulator@lists.csail.mit.edu>
 Dear Tim Berners-Lee ,

The Linked Data Platform (LDP) Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Linked Data Platform 1.0
published on 30 Jul 2013. Thank you for having taken the time to review the
document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-ldp-comments@w3.org if you agree with it or not before 22 November
2013. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Linked Data Platform (LDP) Working Group,
Eric Prud'hommeaux
Yves Lafon
W3C Staff Contacts

 1. http://www.w3.org/mid/4DC77AA1-2559-466C-A1E2-6391039E63E0@w3.org
 2. http://www.w3.org/TR/ldp/


=====

Your comment on :
> 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.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.
> 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.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


Working Group Resolution (LC-2833):
The specification was changed to prevent silent loss of data. See
http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_2

Many MAYs and SHOULDs have been changed to MUSTs as requested.
See http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_3

However, imposing creation of resources via PUT is deemed unpractical at
this time. See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_3

----
Received on Saturday, 16 November 2013 00:59:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:38 UTC