- From: Dmitry Borodaenko <d.borodaenko@sam-solutions.net>
- Date: Fri, 19 Dec 2003 19:12:15 +0200
- To: www-rdf-interest@w3.org
On Thu, Dec 18, 2003 at 07:07:08PM -0500, Thomas B. Passin wrote: > >Why not just reify the statement? > 1) It is complex - you end up with four triples where all you want to > do is to reference a statement. How is non-standard non-triple structure less complex than a mechanism long ago provided by the RDF standard? I think raw number of triples is not the only measure of complexity. > 2) The interpretation of a reified statement is not well defined. For > example, it is NOT a representation for any actual triple in the data > store, and it is NOT considered "asserted"... So what is a reified > statement and how should it relate to the other triples? My understanding is that this question is intentionally left by the spec up to schema and application designers. In my previous example, intended interpretation of "ex:context" property was assertion that the triple under question is asserted by the "http://example.com/" KB. Is there something non-obvious or non-standard about such interpretation? > 3) It is contorted - if a statement had its own resource identifier, > it would be easy and natural to refer to it as the object of an RDF > statement. It seems to me that your use of words "own" and "natural" in this statement is ambiguous: I don't see a reason why these same words wouldn't apply to my example. > And, of course, practical RDF processing systems are likely to have > some internal identifier, so why to make one externally available? And why not make the internal identifier externally available as a proper property? Please check Samizdat to see how I handle statement (and resource) ids and how I use reification to solve the trust problem. Unfortunately, due to the recent Savannah compromise, it is temprorarily unavailable for download, but I can email the 73k tarball of the latest release to anyone who requests it. -- Dmitry Borodaenko
Received on Friday, 19 December 2003 12:13:19 UTC