ld-patch review

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 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.

- 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  <view-source:http://www.w3.org/TR/ldp/#h4_ldpr-HTTP_PATCH>">LDPPATCH</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  <view-source: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  <view-source: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  <view-source: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/  <view-source: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)←
    <https://www.w3.org/2013/meeting/ldp/2014-08-18#resolution_4>

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.

- Please remove the non-normative flag on section 2, since it could 
easily be understood as applying to all of section 2.

- Can we say "partial" instead of "minimal" support for blank nodes?

- 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.

- 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.

- 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.

That's it!

    -- Sandro