There is currently no specification for how a client can determine which patch classes a server supports. The HTTP mechanism only works on content-type, so it doesn't apply when all patches are expressed as RDF datasets. Options include using a profile argument on the content-type, or using a predicate like { ?resource :acceptsPATCH ?patchClass }

Some possible ideas for extensions:

There is no good syntax to use in this document. The SPARQL graph pattern syntax and TriG are almost the same, but they differ in trivial ways, making them incompatible. Perhaps the next draft of TriG will fix this. For now, we'll assume it does, and use a subset of SPARQL as a declarative language, as if it were TriG.

TODO: Explain how users should navigate the overlap in functionality between datapatch and SPARQL 1.1 Update.

Imagine a group of scientists is replicating the classic Stanford marshmallow experiment, where a child is given a marshmallow and offered a second one if they can refrain from eating the first one 15 minutes. In this example, the scientists are looking for cultural variations, so they have recruited collaborators from around the world. Each of the collaborators is given access to the complete dataset and asked to add their own observations each time they run the experiment. The collaborators are granted machine-level access so they can create their own local-language/local-culture experimenter user interface, and they are given free reign to include their own additional data (beyond the common fields such as age of the child, and how long they refrained from eating the first marshmallow).

Client sends:

PATCH /observations HTTP/1.1
Host: www.example.org
Content-Type: text/trig
Transfer-Encoding: Chunked

PREFIX :      <http://www.w3.org/ns/ldp#>
PREFIX xs:    <http://www.w3.org/2001/XMLSchema#>
PREFIX mme:   <http://www.example.org/2013/world-marshmallow-vocab#>
PREFIX univ:  <http://local-universite.example.org/psychlab-vocab#>

 [ a :BasicPatch;
   :where  <#w1>;
   :delete <#d1>;
   :insert <#i1> ]

 <#w1> { }
 <#d1> { }
 <#i1> {
    [ a mme:ExperimentRun;
      mme:observer univ:DrSmith, univ:DrJones;
      mme:countryCode "UK";
      mme:childAge 7;
      mme:secondsLasted 35
    ]
 }

Server responds with a 2xx, indicated success:

HTTP/1.1 204 No Content
Content-Location: /observations
ETag: "e0023aa4f"

    ?patchId a :BasicPatch;
             :where ?w;
             :delete ?d;
             :insert ?i.

    GRAPH ?w {  ... the "W" graph ...  }
    GRAPH ?d {  ... the "D" graph ...  }
    GRAPH ?i {  ... the "I" graph ...  }

  ?patch :onNamed ?NamedGraph
          lets you patch a dataset; you send this PATCH and including this
	  triple to say it applies to a specific named graph
 
  If you don't say this, its just a patch of the default graph.

SHOULD BE:   respect if-match, use if-match.

@@@ Basically, respect if-match.  But *I THINK* the server is allowed to cheat a little, and do a patch even if if-match is wrong, as long as the result would have been the same doing two patches in a different order.

Or not....   Actually as a client, what I want is to be getting a feed of those other people's changes.

If a server gets two or more patches with the same if-match etag it SHOULD merge them (instead of rejecting all but one) as long as the result would be the same AND it has some way to tell the client someone else also made some changes....???

Or I just don't if-match -- I could just patch blindly.

TEST CASE:
   two changes with the same if-match.

what happens???

In practice, it's probably okay to ADD blindly and even DEL blindly, but set/edit/alter  (DEL+ADD) .

@@@ just raw notes.

Basically, the only way to gracefully handle multiple clients doing
patches is if they can also GET patches.

That's pretty easy to do, I think:

  ?resourceURL ldp:nextBasicPatch ?nextPatchURL

  ?resourceURL ldp:nextBasicPatchLongpoll ?nextPatchURL