4.3.1 Bind

The Bind operation is used to bind an RDF Term to a variable. The process results in the variable being bound to exactly one node. After being bound, the variable can be used in the subsequent statements. Another Bind can override the value of a previously bound variable.

The Bind operation is defined by three components: Var, Value and Path, the last component being optional (can be considered equivalent to the empty path).

Var contains a unique name for the new variable. Variables are prefixed by the "?" character, which is not part of the variable name.

Value is the RDF Term that will be used as starting point when following the path expression.

Path is the expression that is used to identify the RDF Term to which the Variable will be bound. It is comprised of Step(s) and/or Constraint(s).

Following the example above, the Bind operation creates a new variable called event, starting from the RDF Term <#> and following the path expression / schema:performerIn [ / schema:url = <https://www.w3.org/2012/ldp/wiki/F2F5> ] in order to identify the RDF Term to which this variable will be bound to – i.e. _:b2 in the target graph.

Bind ?event <#> / schema:performerIn [ / schema:url = <https://www.w3.org/2012/ldp/wiki/F2F5> ] .

4.3.2 Add

The Add operation is used to append new RDF triples to the target graph.

It has a single argument: an argument graph g. All triples in g must be added to the target graph. If an argument graph contains one or more triples that already exist in the target graph, the Add operation does not fail.

Add {
    <#> profile:first_name "Timothy" ;
        profile:image <https://example.org/timbl.jpg> .
} .
Add { ?event rdf:type schema:Event } .

4.3.3 AddNew

The AddNew operation is used to append new RDF triples to the target graph. It behaves like Add but unlike its counterpart, AddNew fails when trying to add an already existing triple.

4.3.4 Delete

The Delete operation is used to remove RDF triples from the target graph.

It has a single argument: an argument graph g. All triples in g must be removed from the target graph. It does not fail if one of those triples did not exist in the target graph. Blank nodes identifiers are allowed in Delete statements but they remain scoped to the LD Patch document, so they can only match a blank node previously added by the same LD Patch document.

Delete { <#> profile:first_name "Tim" } .
Delete { ?ted schema:startDate "2009-02-04" } .

4.3.5 DeleteExisting

The DeleteExisting operation is used to remove RDF triples from the target graph. It behaves like Delete but unlike its counterpart, DeleteExisting fails when trying to delete a non-existing triple.

4.3.6 Cut

The Cut operation is used to remove one or more triples connected to a specific blank node b. More precisely, it removes all the outgoing arcs for b from the target graph, and does the same recursively for all objects of those triples being blank nodes. Finally, it removes all incoming arcs of b.

Cut ?workLocation .

4.3.7 UpdateList

The UpdateList operation is used to update some members of an RDF collection. It works in a similar way to slicing in Python or similar languages: it replaces a slice of a list by another list.

The UpdateList operation is defined by four components: a variable or IRI, a predicate, a Slice expression, and an argument graph containing an RDF collection.

The Slice expression is composed of two optional 0-based indexes i_min and i_max separated by "..". A negative index denotes elements from the end of the list counting backwards, e.g. the last element of any non-empty list always has the index -1. An omitted value is interpreted as the length of the collection. The Slice expression will denote the slice of the list being preceded by i_min elements, and spanning over (i_max - i_min) elements.

For example, here are some Slice expressions for the list ( "lorem" "ipsum" "dolor" "sit" "amet" ):

• 2..4 denotes the slice ( "dolor" "sit" ), i.e. the elements between the indexes 2 and 4
• 0.. denotes the slice ( "lorem" "ipsum" "dolor" "sit" "amet" ), i.e. the whole list
• 3.. denotes the slice ( "sit" "amet" ), i.e. all the elements after the index 3
• -2.. denotes the slice ( "sit" "amet" ), i.e. the last 2 elements
• 2..2 denotes the empty slice located between "ipsum" and "dolor"
• .. denotes the empty slice located at the end of the list

Appendix A contains a detailed algorithm for implementing the UpdateList logic using reified rdf:List.

4.3.8 Error Handling

LD Patch abides to the semantics of the HTTP PATCH method [RFC5789], in that the server MUST apply the entire set of changes atomically and never provide (e.g., in response to a GET during this operation) a partially modified representation. If the entire patch document cannot be successfully applied (e.g., one of the instructions has failed), then the server MUST NOT apply any of the changes. In the case LD Patch operations fail to be applied, Error Handling, Section 2 of [RFC5789] specifies the error codes to be used.

Here are some additional error conditions more specific to LD Patch:

• If a Bind statement fails to match exactly one node, then a HTTP 422 (Unprocessable Entity) error status code MUST be returned.
• If a Unicity constraint is violated, then a HTTP 422 (Unprocessable Entity) error status code MUST be returned.
• If a Cut operation fails to remove any triple, then a HTTP 422 (Unprocessable Entity) error status code MUST be returned.
• If a Cut operation is called on a variable not bound to a blank node, then a HTTP 422 (Unprocessable Entity) error status code MUST be returned.
• If a DeleteExisting attempts to remove a non-existing triple, then a HTTP 422 (Unprocessable Entity) error status code MUST be returned.
• If a AddNew attempts to add an already existing triple, then a HTTP 422 (Unprocessable Entity) error status code MUST be returned.
• If the subject and predicate provided to an UpdateList do not have a unique object, or if this object is not a well-formed collection, then a HTTP 422 (Unprocessable Entity) error status code MUST be returned.
• If the indexes in a slice expression are in the wrong order (e.g. 2868..42), then the parsing fails and a 400 (Bad Request) error status code MUST be returned.
• If an index in a slice expression is greater than the length of the rdf:List, then a 422 (Unprocessable Entity) error status code MUST be returned.
• If a prefix name (PNAME_NS) is used without being previously declared, then the parsing fails and a 400 (Bad Request) error status code MUST be returned.
• If a variable is used without being previously bound, then the parsing fails and a 400 (Bad Request) error status code MUST be returned.

Note: 422 (Unprocessable Entity) is defined in 422 Unprocessable Entity, Section 11.2 of [RFC4918].

4.3.9 Pathological Graph

There exists a particular case which LD Patch is not able to address. Given an RDF graph G, a blank node b is said to be unambiguous in G if there exists a couple (n, p) where

• n is an IRI or a literal
• p is a Path Expression

It is easy to see that only the unambiguous blank nodes of a graph can be handled in LD Patch.

Consider for example the following graph:

<#> foaf:name "Alice" ; foaf:knows _:b1, _:b2 .
_:b1 a foaf:Person .
_:b2 a foaf:Person ; schema:workLocation _:b3 .
_:b3 schema:name "W3C/MIT" .

The blank nodes _:b2 and _:b3 are unambiguous as they can be reached unambiguoulsy from the literal "W3C/MIT". The blank node _:b1, on the other hand, is ambigious as all path expressions that can match it would also match _:b2.

Another example is a graph containing only blank nodes. All its nodes are therefore ambiguous as they can not be reached from an IRI or a literal. Such a graph is not interesting in the context of Linked Data as it contains no IRI to link to or from it.

Therefore, ambiguous blank nodes are considered a pathological case in the context of Linked Data, and so the fact that they cannot be coped with in LD Patch is deemed acceptable. Furthermore, their presence in a graph does not prevent the other nodes of that graph to be handled by LD Patch. Most notably, all non-lean graphs [rdf11-mt] are also pathological.