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

Re: Contextualization ---> Optional bundle in Specialization

From: Timothy Lebo <lebot@rpi.edu>
Date: Thu, 28 Jun 2012 10:44:05 -0400
Cc: Graham Klyne <graham.klyne@zoo.ox.ac.uk>, Paul Groth <p.t.groth@vu.nl>, Luc Moreau <L.Moreau@ecs.soton.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
Message-Id: <5A7448BA-697F-48DD-905F-8D9C132E7E23@rpi.edu>
To: James Cheney <jcheney@inf.ed.ac.uk>
James,



On Jun 28, 2012, at 10:34 AM, James Cheney wrote:

> Hi,
> 
> It's become difficult for me to track what is going on in this thread, so let me try to summarize what I (think I) understand... 


Thanks for a great overview of the discussions.
It really helps.


> I guess this topic has been beaten out of DM.
>> 
>> So I'll press on in my applications with dcterms:isReferencedBy [ a prov:Bundle ] and not lose any sleep.
>> 
>> -Tim
> 
> 
> It seems to me that we may have been talking at cross purposes by conflating two proposals: 
> 
> 1. what is in PROV-O (ctxOf = specializatioOf + inBundle) - which seems totally innocent to me

+1 :-)

> 
> and 
> 
> 2.  the much stronger-sounding ctxOf that was in the previous draft of PROV-DM (which talked about linking entities with respect to different contexts, which Graham points out opens a big can of worms)


If it's anything more than 1), then YES, it goes into scary areas that we should be (and have been) avoiding.


> 
> I understood the resolution to Graham's concerns about (2) at the WG meeting to just involve changing ctxOf to some mutually agreeable name, and keeping the section as is (marked "at risk")

+1

> 
> My earlier negative reaction was to changing from (2) to this:
> 
> 3.  overloading specializationOf to allow an optional bundle parameter, which (if I understand right) would be equivalent to saying "specializationOf + inBundle" in PROV-O.


I think that this is a legitimate concern. Sorry, I hadn't seen that laid out earlier in this thread (which I've only tersely handled).

> 
> This was partly because of the change in meaning, but mostly because it seemed to exceed the scope of the renaming resolution, and at the same time muddies the waters about specializationOf. 

+1 The reason to push "contextualizationOf" into an optional parameter was because we were avoiding a name for "contextualization" - what better way to avoid a name than to make it a parameter :-) Yes, we punted.

I think Luc has recently named it "Mention", to give the 3-ary a name separate distinct from specialization. 

> 
> I don't object to keeping a 3-ary relation that corresponds to PROV-O's specialization + inBundle pattern (as long as it is not an overload of a name already defined in the vocabulary).  

+1

> 
> But, your suggestion of using another term from DC seems sensible as a stopgap

I'd rather not fall back to this. But whatever.



> (perhaps this suggestion could go into the DC mapping document too).


+1

-Tim



> 
> --James
> 
>> 
>> 
>> 
>>> 
>>> #g
>>> --
>>> 
>>>> 
>>>> On Jun 27, 2012, at 19:48, Graham Klyne<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>  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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
Received on Thursday, 28 June 2012 14:45:00 UTC

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