- From: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- Date: Wed, 27 Jun 2012 23:57:24 +0100
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- CC: Jim McCusker <mccusj@rpi.edu>, Paul Groth <p.t.groth@vu.nl>, Provenance Working Group WG <public-prov-wg@w3.org>
On 27/06/2012 22:21, Luc Moreau wrote: > 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. Quite. So what basis is there for claiming that two specializations of ex:Bob are somehow distinct, and that inferences that are true for one such specialization are not true for the other? #g -- > 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 Thursday, 28 June 2012 08:46:15 UTC