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

Re: Abstract syntax: an attempt

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Sun, 17 Jun 2001 17:04:59 -0700
Message-ID: <3B2D45AB.BDDF0115@db.stanford.edu>
To: Brian McBride <bwm@hplb.hpl.hp.com>
CC: Graham Klyne <Graham.Klyne@Baltimore.com>, w3c-rdfcore-wg <w3c-rdfcore-wg@w3.org>

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


Brian McBride wrote:
> Hi Graham,
> Thanks for this.  One question:
> Graham Klyne wrote:
> >
> > NOTE:  "reification" is deliberately called out as a distinct syntax
> > production, so that there is a place to hang the semantics that distinguish
> > it from any other collection of facts.  There is some syntactic ambiguity
> > here that needs to be resolved at some level;  e.g. adjusting the abstract
> > syntax so that rdf:subject, rdf:object, rdf:predicate can appear *only* in
> > a production for R (and not for A).
> In M&S 1.0 the statements of a reification (i.e. the rdf:type, rdf:subject,
> etc ...) are no different from other statements.  What difference are
> you considering introducing here?
> Brian
Received on Sunday, 17 June 2001 19:52:10 UTC

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