W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Concerns about reification

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Fri, 15 Feb 2002 10:11:57 -0800
Message-ID: <3C6D4F6D.3599A485@db.stanford.edu>
To: RDFCore WG <w3c-rdfcore-wg@w3.org>
CC: Frank Manola <fmanola@mitre.org>
Brian asked me (for the Xth time, sigh) to express my concerns about
reification in writing. My position remains that we need an
interoperable and efficient way of doing reification.

If we go for "stating" (answer "No" to Q1 in [1]), no special semantics
is associated with the vocabulary rdf:Statement, rdf:subject,
rdf:predicate and rdf:object. This means applications *cannot
interoperate* using this vocabulary since its meaning is unspecified.
Effectively, going for "stating" amounts to deprecating 4-triple
reification as used today.

If we go for "statement" (answer "Yes" to Q1 in [1]), we get a (rather
painful, admittedly, but endorsed) way of referring to statements found
on Web pages and in RDF databases, recording provenance etc. This is IMO
much more concrete and useful that just providing no definition at all,
although the usability of 4-triple reification still remains seriosly
hampered by its verbosity.

In summary, if we go for "stating" we have *no* official mechanism for
reification. In this case we'd have to suggest an alternative, we cannot
just wash our hands. It is an illusion that we can leave the vocabulary
undefined and at the same time recommend developers to use it in a
consistent way. If we go for "statement" we do have a solution, albeit a
poor one. If we run out of time in finding an alternative *efficient*
way of doing reification, we could of course fall back on "statement"
expressed using 4 triples. In this case, we would not have achieved much
since inefficiency proved to be a show stopper for using 4-triple
reification in the past 3 years.


[1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0359.html
Received on Friday, 15 February 2002 14:40:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:10 UTC