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

--Frank

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

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:37:11 EDT