- From: Sergey Melnik <melnik@db.stanford.edu>
- Date: Tue, 05 Feb 2002 12:13:34 -0800
- To: RDFCore WG <w3c-rdfcore-wg@w3.org>, "McBride, Brian" <bwm@hplb.hpl.hp.com>
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