Re: 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).

OK

>
>- 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...)

That sounds like saying that reification does not use reification. 
The 4-triple form IS reification in RDF, right? If not, what do you 
mean by 'reification' here?

>- Existence of a reified statement does not imply the existence of the
>corresponding asserted statement.

OK, but...

>Each asserted statement can be viewed
>as also (implicitly) existing in its reified form.

....what does that mean, 'implicitly existing' ? Is it a valid 
inference from a triple to its reified form? I hope not, see below.

>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.

What a VERY good idea. In other words, RDF reification is not used.

>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!).

Or, better, why not just trash it, since apparently nobody uses it anyway.

>
>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.

No trick is needed. The ordinary MT already would treat the 4-triples 
in this way already; reification is semantically transparent, on this 
view. Which is another way of saying that we are trashing it. After 
all, there's no way to stop anyone writing those 4-triples if they 
want to, right? Trashing it doesn't make it illegal, it just says 
that we aren't saying anything particular about what it means: its 
not a language feature, its just a way you might want to write some 
RDF. Go ahead if y'all feel like it.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Wednesday, 6 February 2002 13:25:15 UTC