- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Wed, 27 Jun 2012 22:21:00 +0100
- To: Jim McCusker <mccusj@rpi.edu>
- CC: Paul Groth <p.t.groth@vu.nl>, Graham Klyne <graham.klyne@zoo.ox.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
- Message-ID: <EMEW3|2170373ebc38fe06d8fe64b008dec7e1o5QML108L.Moreau|ecs.soton.ac.uk|4FEB793C>
Hi Jim, ex:Bob refers to a single resource in this example. The interpretation of ex:Bob does not change according to the graph it occurs in. Luc On 27/06/12 19:33, Jim McCusker wrote: > What Graham is objecting to (I think) is the idea that ex:Bob in one > graph is referring to something different from what ex:Bob is > referring to in another graph. That's not possible in RDF, as while we > can have more than one symbol (IRI) denote the same resource, it's by > definition impossible for a symbol to denote multiple resources in > different contexts. The symbol is universally scoped if it is an IRI. > If it is not universally scoped, it needs to be anonymous or skolemized. > > GK, correct me if I misunderstood. > > Jim > > On Wed, Jun 27, 2012 at 2:21 PM, Paul Groth <p.t.groth@vu.nl > <mailto:p.t.groth@vu.nl>> wrote: > > So the use case is the issue? > > I really don't get how the example breaks any semantics. Sorry... > > So I think that your approach to allowing a qualified > specialization would be fine with me especially if we add a > inBundle predicate that identifies a bundle. but Tim was really > really against this because of the increased number of triples. > > Paul > > > On Jun 27, 2012, at 19:48, Graham Klyne <graham.klyne@zoo.ox.ac.uk > <mailto:graham.klyne@zoo.ox.ac.uk>> wrote: > > > On 27/06/2012 18:39, Paul Groth wrote: > >> Hi Graham > >> > >> These are two different urls so they identify different things. > > > > Not necessarily, There is no unique-name assumption in RDF. > They could denote > > the same thing. > > > >> The fact that we add some properties like bundle or > specializationof doesn't break anything. I can do that with any > resource on the web, no? > > > > Adding the properties per se doesn't break anything, but when > they are presented > > as addressing a use-case that I don't believe can be addressed > by RDF semantics, > > they run the risk of encouraging people to creating RDF data > that doesn't mean > > what they think it means when interp[reted in accordance with > RDF semantics. > > > > #g > > -- > > > >> Paul > >> > >> On Jun 27, 2012, at 19:09, Graham > Klyne<graham.klyne@zoo.ox.ac.uk > <mailto:graham.klyne@zoo.ox.ac.uk>> wrote: > >> > >>> On 27/06/2012 10:49, Luc Moreau wrote: > >>>> All, > >>>> > >>>> At the face to face meeting, we have agreed to rename > contextualization and mark > >>>> this feature > >>>> at risk. Tim, Stephan, Paul and I have worked a solution that > we now share with > >>>> the working group. > >>> > >>> I'm afraid I still have a problem with this. > >>> > >>> Considering your bundle tool:analysis01: > >>> [[ > >>> bundle tool:analysis01 > >>> agent(tool:Bob-2011-11-16, [perf:rating="good"]) > >>> specializationOf(tool:Bob-2011-11-16, ex:Bob, ex:run1) > >>> > >>> agent(tool:Bob-2011-11-17, [perf:rating="bad"]) > >>> specializationOf(tool:Bob-2011-11-17, ex:Bob, ex:run2) > >>> endBundle > >>> ]] > >>> > >>> The problem is that, if subject to RDF semantics for URI > interpretation, I can > >>> see no semantic distinction is possible between > >>> > >>> tool:Bob-2011-11-16 > >>> and > >>> tool:Bob-2011-11-17 > >>> > >>> I.e. they are both specializations of ex:Bob, and that is all > we can know about > >>> them, as (by the nature of the semantics of URI > interpretation) the denotation > >>> of ex:Bob that appears in ex:run1 is the same as the > denotation of ex:Bob that > >>> appears in ex:run2. > >>> > >>> ... > >>> > >>> I do, however, have a different compromise that provides a > hook for introducing > >>> possible semantics later, or in private implementations, > without sneaking in > >>> something that could well turn out to be incompatible with, or > just different > >>> than, what the RDF group may do for semantics of datasets. > >>> > >>> The hook is this: simply allow attributes for the > specializationOf relation, but > >>> don't define a specific attribute for bundle. This would > allow you to do a > >>> private implementation of the scheme you describe, but would > not allow it to be > >>> mistaken for something that has standardized semantics. As in: > >>> > >>> specializationOf(tool:Bob-2011-11-17, ex:Bob, > >>> [myprivateattribute:bundle=ex:run2]) > >>> > >>> ... > >>> > >>> In case you think I'm jumping at shadows here, I'll note that > RDF has been here > >>> before. The original 1999 RDF specification described > reification without > >>> formal semantics. Reification was intended to allow for > capturing this kind of > >>> information - i.e. to make assertions about context of use, > etc - a kind of > >>> proto-provenance, if you like. But when the group came to > define a formal > >>> semantics for RDF, there were two possible, reasonable and > semantically > >>> incompatible approaches; looking at the way that reification > was being used "in > >>> the wild", it turned out that there was data out there that > corresponded to both > >>> of these (incompatible) approaches. This was in the very > early days of the > >>> semantic web, so the harm done was quite limited. I think a > similar mistake > >>> today would cause much greater harm. > >>> > >>> I think the appropriate way forward is to take this tool > performance analysis > >>> use-case to the RDF-PROV coordination group, and ask that it > be considered as > >>> input when defining semantics for RDF datasets. I would > expect that whatever > >>> semantic structure they choose, it should be able to > accommodate the use-case. > >>> Then, we should be better placed to create an appropriate and > compatible > >>> contextualization semantics for provenance bundles. But until > then, I think we > >>> invite problems by trying to create a standardized data model > structure without > >>> standardized RDF-compatible semantics to accommodate this > use-case. > >>> > >>> #g > >>> -- > >>> > >>> Tracker, this is ISSUE-385 > >>> > >>> On 27/06/2012 10:49, Luc Moreau wrote: > >>>> All, > >>>> > >>>> At the face to face meeting, we have agreed to rename > contextualization and mark > >>>> this feature > >>>> at risk. Tim, Stephan, Paul and I have worked a solution that > we now share with > >>>> the working group. > >>>> > >>>> Given that contextualization was already defined as a kind of > specialization, we > >>>> now allow an optional > >>>> bundle argument in the specialization relation. (Hence, no > need to create a new > >>>> concept!) > >>>> > >>>> See section 5.5.1 in the current Editor's draft > >>>> > http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-specialization > >>>> > >>>> Feedback welcome. > >>>> > >>>> Regards, > >>>> Luc > >>>> > >>>> PS. Tracker, this is ISSUE-385 > >>>> > >>> > >> > >> > > > > > -- > Jim McCusker > Programmer Analyst > Krauthammer Lab, Pathology Informatics > Yale School of Medicine > james.mccusker@yale.edu <mailto:james.mccusker@yale.edu> | (203) 785-6330 > http://krauthammerlab.med.yale.edu > > PhD Student > Tetherless World Constellation > Rensselaer Polytechnic Institute > mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu> > http://tw.rpi.edu
Received on Wednesday, 27 June 2012 21:21:39 UTC