summary of reification?

Brian,

after your excellent job of summarizing datatyping periodically, I feel
a desire for your summary of reification, so once you get to it... ;)

I did not follow the recent postings all too closely, but here is a
scoop of how reification is currently used in some commercial
applications I helped with.

- (Reified) statements are first-class objects in the programming
language, just like resources and literals. For example, they can be
used in the object position of another statement. At the API and storage
level, the URI-identity of (reified) statements is irrelevant (no URIs
are used/generated).

- Efficient exchange of RDF data that contains reified statements is
done using an alternative RDF syntax, which supports compact XML
representation of reified statements (I guess, the 4-triple form could
be used as well, but it's just waaay too verbose for exchange and needs
special care during parsing...)

- Existence of a reified statement does not imply the existence of the
corresponding asserted statement. Each asserted statement can be viewed
as also (implicitly) existing in its reified form. The predicates
rdf:subject, rdf:predicate and rdf:object and never used. A query like
(X, rdf:subject, <uri>) is stated as X = (<uri>, wildcard, wildcard)
instead.

In the above approach, neither bNodes, nor additional 4 triples are ever
used for dealing with reification. In this perspective, our decision on
reification would probably have no impact on the implementation. Maybe
we should not be all too academic and/or religious about how to
formalize reification properly. We could just simply move it out of the
way quickly and focus on making the use of reification more
interoperable and efficient (specifically, I hate using an alternative
syntax!).

I see two ways of how the semantics of reification could be attacked:

1. Explain the semantics using bNode + 4-triple constructs. Applications
are free to use a compact representation. If statements are used as
first-class objects, they can be treated just as some kind of bNodes.
The API-level identity of such bNodes is functionally determined by
their (s,p,o)-description. Alternatively, the applications can generate
exactly one such bNode for each (s,p,o) etc. Same trick could be applied
for  dealing with functionally determined bNodes in the model theory.

2. Extend the abstract model of RDF (currently a simple graph) to a
nested graph-like model. The trouble of "functionally determined bNodes"
goes away, but the model theory becomes (even) more sophisticated. Feels
like pain.

Sergey

Received on Tuesday, 5 February 2002 14:43:24 UTC