ioctl

ioctl's RDF junkyard.

Options for reification

Reification is a mechanism to record statements without asserting them. Prime uses include provenance (who said what). How do you do it?

A parameterised definition of reification

A resource R is said to be a reification in the graph G of a statement of the form S P O (which itself does not have to appear in G) iff the following statements appear in G:

• R <rdf:type> <rdf:Statement>
• R <rdf:subject> f(S)
• R <rdf:predicate> f(P)
• R <rdf:object> f(O)

...and the various definitions of f give you different options for a definition of reification.

The case f = id: Fred said that Mary had a lamb

This is as reification was 'classically' defined in the M&S. (Note: I'm just talking here about the assertions needed to put a reificaiton of a statement into a graph, not about the other machinery that M&S talks about.)

The prime objection to this seems to be that there's a use/mention problem here. The validity of that complaint depends upon how you pronounce the various property names.

The case f = quote: Fred said, "Mary had a lamb"

Let's take, for a moment, the point of view that there really is a use/mention problem above. Then we need a better definition of f in the following three cases:

1. f(X) = ? iff X is a resource label
2. f(X) = ? iff X is a literal
3. f(X) = ? iff X is an anonymous (blank) node

The definition of f must satisfy the following properties:

• the range of f is the union of (RDF resources, RDF literals, blank nodes) - since reification is representing an RDF statement within RDF;
• ∀X f(X) ≠ X, because otherwise we're falling into the use/mention trap above [ Note: if your browser doesn't render that correctly, that's "for all X, f(X) <> X" ];
• f had better be injective, because otherwise there will be multiple, differing statements that have the same reification;
• f had better also be single-valued, because the reification of a statement ought to look the same every time (in particular, the reifications of _:a <eg:foo> <eg:bar> and _:a <eg:foo> <eg:baz> had better have the same <rdf:subject>s;
• the definition of f should not rely on context. That is, the reification of a statement should not change depending on what other statements may be being reified or the contents of the graph into which the reification is made;
• the definition of f should not rely on magic; that is, it should be computable.

There is no such f. Which means that we are stuck with f = id, and have to adjust our thinking accordingly. The thing that really scotches this is the existence of blank nodes; however, naive partial definitions for f such as "the characters (making up the URI of a resource label) as a literal, or just the literal itself" fall foul of the injectiveness requirement.

Proof

Following DanC, I assert that I'm right and leave the proof as an exercise to people with more energy and enthusiasm for details; however... as a pointer, the handling of blank nodes is where the problem lies. As DanC himself commented at the first RDF WG F2F, "if I'd had to invent names for all these [blank nodes] then those programs would never had been written," indicating how hard this problem is. Fortunately, there is now a good precedent for "we've got a vocabulary, sod the model-theory, the semantics of this is defined by the application" (see the Bag, Sequence, Alternation treatment) so there really isn't a cause for concern - we can certainly make programs grok the former form of reification.

A pint to Danbri if he can (by demonstration, that is, by producing a working definition) prove me wrong.