W3C home > Mailing lists > Public > public-ldp-wg@w3.org > September 2014

Re: ld-patch review

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 02 Sep 2014 10:56:45 -0400
Message-ID: <5405DAAD.2070109@w3.org>
To: Alexandre Bertails <alexandre@bertails.org>
CC: Linked Data Platform WG <public-ldp-wg@w3.org>
On 08/26/2014 09:59 AM, Alexandre Bertails wrote:
> Thank you for the review. You can find the changes implemented in [1]
> and my comments in-line:

Sorry for the delay.  Great job.   I'm fine with this now moving to FPWD.

      -- Sandro

>
> [1] https://dvcs.w3.org/hg/ldpwg/rev/503808034312
>
> On Mon, Aug 25, 2014 at 10:24 PM, Sandro Hawke <sandro@w3.org> wrote:
>> Okay, sorry to be a pain, but I see a few problems with the current text.
>> I wouldn't think any would be controversial or hard to fix.
>>
>> I was looking at:
>> https://dvcs.w3.org/hg/ldpwg/raw-file/66030a2d0f9f/ldpatch.html
>>
>>
>> Major concerns (must be addressed before publication):
>>
>> - I don't think we can claim "text/ldpatch" without talking to the IETF
>> first.   Unless someone is sure about this, best to take it out for now.
>> Maybe put in an empty appendix saying "Media type registration will go here"
>> to remind us all this has to be done.
> I have removed the mentions of the media type in the introduction, and
> added the phrase [[ The "text/ldpatch" media type is _prospectively_
> used to identify such LD Patch documents. ]] in the example making use
> of it. I have also created the section and left it empty.
>
>>   I suspect it will end up in
>> application, too.      Also, can we us ldpatch or ld-patch everywhere, and
>> not switch between them?    That is, the TR name should match the media type
>> in this regard.
> Why not. I am now going with "ldpatch" (no dash) for the short
> version, and "LD Patch" when referring to the name of the technology.
>
>> - The "considered alternatives" section misreads the resolution to publish
>> [1].  The understanding on which I supported publication was that we present
>> ourselves as having an open mind, not that we've already decided.    Why
>> would we ask for feedback if we've already decided?    Here's some text
>> which fits what I had in mind.   This kind of text should be styled as a
>> NOTE or be in a box in the SOTD, not free-standing as spec text in the
>> draft.
>>
>> <h2 id="alternative-designs">Alternative Designs</h2>
>>
>>        <p>
>>     Although the Linked Data Platform (LDP) Working Group is currently
>> favoring LD-Patch, it seeks more input in deciding which format to promote
>> for use in <a href="http://www.w3.org/TR/ldp/#h4_ldpr-HTTP_PATCH">LDP
>> PATCH</a> operations on of RDF Sources.  Other viable candidates
>> include:</p>
>>
>>        <ul>
>>   <li><a
>> href="http://www.w3.org/TR/sparql11-http-rdf-update/#http-patch">SPARQL 1.1
>> Update</a> &mdash; already standardized, but quite complex for LDP
>> scenarios</li>
>>   <li><a
>> href="http://www.w3.org/2012/ldp/wiki/LDP_PATCH_Proposals#EricP.27s_proposal">SPARQL
>> Patch</a> &mdash; restricted to a simple subset of SPARQL 1.1 Update </li>
>>   <li><a href="http://www.w3.org/2001/sw/wiki/TurtlePatch">TurtlePatch</a>
>> &mdash; uses an even simpler subset, but requires unusual handling of blank
>> nodes</li>
>>   <li><a href="http://afs.github.io/rdf-patch/">RDF Patch</a> &mdash;
>> simple, but also requires unusual handling of blank nodes </li>
>>         </ul>
>>
>>        <p>
>>   At this point, the advantage leans towards LD-Patch in terms of
>> simplicity, ease of implementation, and run-time performance on anticipated
>> data.  We welcome data relevant to this decision.
>>        </p>
>>
>> [1] https://www.w3.org/2013/meeting/ldp/2014-08-18#resolution_4 : Publish
>> LD-PATCH as FPWD with inverse path and slice syntax fixed, possibly other
>> raised issues (eg slash syntax), links to sandro's and eric's proposal
>> (explaining we're asking feedback about which direction to go) ←
> I don't see how much your wording changes much, but I am fine with it,
> so I used it unchanged. That's shorter than my version, which is good
> :-)
>
> I guess it's a good candidate for the sotd, so I went with that. I
> don't think we need a special styling when used in that position.
>
>> Minor concerns (should be addressed before publication):
>>
>> - There should be a proper references section, with at least a couple
>> references, eg for HTTP PATCH and LDP.
> Done with a few others.
>
>> - Please remove the non-normative flag on section 2, since it could easily
>> be understood as applying to all of section 2.
> Even if detailed, Section 2 was meant to be informative as it doesn't
> specify the syntax nor the semantics formally. Next sections are for
> that effect.
>
>> - Can we say "partial" instead of "minimal" support for blank nodes?
> Sure. Done.
>
>> - schema:attendee is still broken (backwards).   As per
>> http://schema.org/attendee , an Event has an attendee which is a person,
>> while you have it the other way around.  The easiest fix would be to make up
>> attendeeOf in another namespace.
> Good catch. I went with <https://schema.org/performerIn> instead.
>
>> - I find the example use of [ = ] being a URL to be really weird.  While
>> it's not actually bad RDF modeling, it looks as if it were, which I think
>> will mislead readers.  I suggest getting rid of the URLs for the events and
>> just use their names.
> I am not sure to understand your concern, and why you relate it to
> "RDF modeling". I am inclined to leave it as it is.
>
>> - Personally, I don't like the stuff in the intro about how this is all
>> about LDP, not really about RDF, but I guess you put that there for Andy?  I
>> don't really care.
> The main abstract is still about "RDF Graph". LDP and "Linked Data
> Platform" are only mentioned along with Working Group (I fixed the one
> place it wasn't the case). I think Andy's remark on LD Patch being
> resource-centric -- when compared to the database-centric approach of
> SPARQL (my words) -- was important, hence the use of Linked Data in
> some places, without the 'P'.
>
>> That's it!
> Thank you for the thorough review. Can you please confirm you are fine
> with the changes I made?
>
> Alexandre
>
>>     -- Sandro
>>
>>
>>
Received on Tuesday, 2 September 2014 14:56:47 UTC

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