W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2001

Re: Abstract syntax: an attempt

From: Frank Manola <fmanola@mitre.org>
Date: Sun, 17 Jun 2001 20:17:51 -0400
Message-ID: <3B2D48AF.3A0536FD@mitre.org>
To: Sergey Melnik <melnik@db.stanford.edu>
CC: w3c-rdfcore-wg <w3c-rdfcore-wg@w3.org>
Sergey Melnik wrote:
> Brian,
> I'd just like to reiterate some of the arguments for making reification
> a built-in feature (possibly as an optional layer):
> - in M&S, reified statements need to have a URI. It looks like they
> should be unique, but nobody wants to deal with uniqueness, but still
> some sort of URIs need to be assigned, so we end up having to deal with
> different URIs denoting the same statement etc.
> - in M&S, we need a specific vocabulary to express/use reification.
> Reification could be defined without relying on vocabularies.
> - as defined in M&S, reification is extremely verbose and clumsy both in
> APIs and in the syntax, and very few people are using it as suggested.
> However, I personally believe it is a useful feature when introduced
> correctly and compactly, and it can be easily handled in APIs and
> databases as an intrinsic model feature.
> Finally, (s1 p1 (s2 p2 o2)) looks nicer in the abstract syntax...

I, for one, would find it easier to follow these discussions if we
distinguished the "reification" that is currently defined in the M&S
(which involves creating multiple triples, rather than nesting the
triple that is to be reified) from alternative notations like (s1 p1 (s2
p2 o2)).  I agree the latter is much nicer, but I didn't understand,
when Sergey said that reification was a useful feature, that he was
referring to a different way of doing it, until I got to the last bit. 
(Now all we need to do is be precise about what it's supposed to


Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752
Received on Sunday, 17 June 2001 20:18:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:49 UTC