Prefixes

LD Patch offers the possibility to abbreviate URIs by using Turtle's @prefix directive that allows declaring a short prefix name for a long prefix of repeated URIs. This is useful for many RDF vocabularies that are all defined in nearby namespace URIs, possibly using XML's namespace mechanism that works in a similar fashion.

Once a prefix such as @prefix foo: <http://example.org/ns#> is defined, any mention of a URI later in the document may use a PrefixedName that starts with foo: to stand for the longer URI. So for example, the PrefixedName foo:bar is a shorthand for the URI <http://example.org/ns#bar>.

Node matching semantics

LD Patch borrows much of its syntax to Turtle (@@@ref) and SPARQL (@@@ref) for describing nodes. IRIs (either abbreviated or not) and literals represent the corresponding node in the graph being patched. Blank nodes, on the other hand, pose a problem, as they have no global identifier. Indeed, blank node identifiers have their scope limited to the document in which they appear. As a consequence, whenever a blank node identifiers appears in an LD Patch document, it is understood to denote a fresh blank node, that needs to be created in the patched RDF graph. (@@@ remark that this is different from RDF-Patch)

In order to be able to address blank nodes already present in the graph, LD Patch has two mechanisms: Binding a variable to a blank node reachable with a path expression, and UpdateList to deal with those blank nodes that constitute RDF collections. There are cases where those mechanisms will not be able to unambiuously adress a given blank node, but those cases are deemed pathological, and out of the scope of this specification. (@@@give here an example of pathological graph)

Path expression

LD Patch uses path expressions to describe possible routes through a graph between two graph nodes. The main goal is to allow addressing a blank node by “walking” the arcs of the graph from an already identified node. A path is composed by a number of steps, which can be of three kinds:

• A StepForward is defined by a URI, and consists in following outgoing arcs having that URI as their predicate.
• A StepBackward is defined by a URI preceded with the minus ("-") sign, and consists in following incoming arcs having that URI as their predicate.
• A StepAt is defined by an integer n, and consists in following n rdf:rest arcs and one rdf:first arc in order to reach the corresponding member of an RDF collection.

Note that each step can, in general, result in several matching nodes, as a given node can have several (incoming or outgoing) arcs with the same predicate.

A Path may also contains Constraints, which are of two kinds:

• A unicity constraint, described by the bang ("!") character, ensures that the result of the path so far contains exactly one node.
• A filter, consisting of a path in square brackets ("[", "]"), keeps only from the matching nodes so far those that “satisfy” the enclosed path, i.e. those from which the enclosed path reaches at least one node.
• Additionally, the path in a filter can be followed by the equal ("=") sign and a Value. In that case, only the node for which that particular value is reached through the enclosed path are kept.

The path below (taken from our running example) will look for all the events attended by the starting node, and keep only those having <http://conferences.ted.com/TED2009/> as their URL.

/schema:attendee[/schema:url = <http://conferences.ted.com/TED2009/>]
        

Bind

The Bind operation is used to create a new variable by binding or assigning an RDF Term to the variable. The bound variable has a global scope. Use of a given variable name anywhere in an LD Patch document identifies the same variable (@@@ but a variable _can_ be redefined). Following the example above, the Bind operation creates a new variable called event, starting from the RDF Term <#> and following the path expression /schema:attendee[/schema:url = <http://conferences.ted.com/TED2009/>] in order to identify the RDF Term to which this variable will point -- i.e. _:b2.

...
Bind ?event <#> /schema:attendee[/schema:url = <http://conferences.ted.com/TED2009/>] .
...
        

The Bind operation is defined by three components: Var, Value and Path, the last component being optional.

Var contains a unique name for the new variable. Variables are prefixed by "?"; the "?" character 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 point. It is comprised of Step(s) and/or Constraint(s).

Add

The Add operation is used to add or append new RDF triples to the existing graph. To add new RDF triple, the operation requires a Subject, a Predicate and either an Object or a List.

...
Add    <#> profile:first_name "Timothy" .
...
Add ?event rdf:type schema:Event .
...
        

Delete

The Delete operation is used to remove a single RDF triple from the existing graph. The syntax for the Delete operation requires a Subject, a Predicate and an Object.

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

UpdateList

The UpdateList operation is used to update the members of an RDF collection (@@@ref). That collection is supposed to be the object of a triple, specified by its Subject and Predicate. A Slice specification then describes which members (if any) of the collections are affected by the operation, and then a List of new members is provided. In the example below, UpdateList is used to replace the second member of a collection by the literal "fr-CH".

...
UpdateList <#> ex:preferredLanguages 1>2 ( "fr-CH" ) .
...
        

UpdateList works in a similar way to slicing in Python or similar languages. In general, it replaces a part (“slice”) of a list by another list. To remove members, one can replace them by an empty list. To insert new values between two members, one can set a non empty list to the empty slice comprised between those two members.

In LD Patch, a slice is described by two positive integers separated by ">". The second integer can be omitted, in that case it denotes the end of the list. If both integers are omitted (i.e. ">" alone), this denotes by convention the empty slice at the end of the list. @@@TODO eplain that indexes start at 0 @@@TODO give some examples here.