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

Re: doing provenance in RDF 1.0 clarified

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Sun, 10 Feb 2002 21:07:55 +0000
Message-Id: <>
To: Dan Brickley <danbri@w3.org>
Cc: Brian McBride <bwm@hplb.hpl.hp.com>, <w3c-rdfcore-wg@w3.org>
At 12:57 PM 2/10/02 -0500, Dan Brickley wrote:
>On Sun, 10 Feb 2002, Brian McBride wrote:
> > At 16:14 10/02/2002 +0100, jos.deroo.jd@belgium.agfa.com
> > [...]
> >
> > >and Statement is according to a "yes" on DanBri's entailment test case
> >
> > A simple way to interpret the vote at Friday's telecon is that we decide
> > that an rdf:Statement represents a stating (an occurence of a
> > statement).  Would that then imply that the entailment does not follow;
> > i.e. that two resources with the same values for their subject, predicate
> > and object properties may denote different statings.
>I would be happy taking this route. Several people (including myself) have
>expressed concern that "doing the provenance thing properly" could be a
>big job. I think taking the route outlined above, where rdf:Statement had
>multiple members with the same p/s/o characteristics, would be
>very useful progress towards making RDF's reification vocab work for 

Me too.

>Such a clarification of rdf:Statement would set things up so that others
>(eg. via a Note, via later work of this WG or another, whatever) could
>provide further properties that better describe the characteristics of an
>rdf:Statement. For example, DanC and I might define util:predicateURI,
>util:subjectURI, util:ObjectURI, each having rdfs:domain of rdf:Statement,
>to address the concerns aired in the use/mention/superman thread. By
>agreeing that rdf:Statement's members aren't individuated by p/s/o, we'd
>lay the groundwork for future improvements to reification.

That's a very interesting insight.


Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
Received on Sunday, 10 February 2002 17:31:08 UTC

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