W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2012

Re: Contextualization ---> Optional bundle in Specialization

From: James Cheney <jcheney@inf.ed.ac.uk>
Date: Thu, 28 Jun 2012 09:32:59 -0500
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>
Message-Id: <6B04A805-F4F9-45D6-AE6F-A551295119C6@inf.ed.ac.uk>
To: Timothy Lebo <lebot@rpi.edu>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:16 UTC