- From: James Cheney <jcheney@inf.ed.ac.uk>
- Date: Thu, 28 Jun 2012 09:32:59 -0500
- To: Timothy Lebo <lebot@rpi.edu>
- Cc: Graham Klyne <graham.klyne@zoo.ox.ac.uk>, Luc Moreau <L.Moreau@ecs.soton.ac.uk>, Jim McCusker <mccusj@rpi.edu>, Paul Groth <p.t.groth@vu.nl>, Provenance Working Group WG <public-prov-wg@w3.org>
On Jun 28, 2012, at 6:59 AM, Timothy Lebo wrote: > > On Jun 27, 2012, at 6:57 PM, Graham Klyne wrote: > >> 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, > > One doesn't know whether the specializations are distinct or if they are unique. > We do know that they are prov:alternates :-) > >> and that inferences that are true for one such specialization are not true for the other? > > We don't, since we can't prove identity or distinctness. > Yes, (just to butt into this subthread), I'm afraid I agree that Graham's reasoning is faulty there. At a meta-level, given: specializationOf(a,c) specializationOf(b,c) Sure, anything we can prove (i.e. not much) about a, we could also prove about b, since they're indistinguishable; but we can't prove a = b because of this. It's possible for the two statements to hold in a model where a = b or in a model where a \neq b (they must be alternates of course). --James > -Tim > > >> >> #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 >>> >> >> > > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Received on Thursday, 28 June 2012 14:33:37 UTC