Re: Contextualization ---> Optional bundle in Specialization

Thanks. Fixing it.
Luc

On 28/06/12 16:19, Graham Klyne wrote:
> Just for the process:
>
> at: http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html
>
> I'm still seeing:
>
> A specialization ◊ relation, written specializationOf(infra, supra, b) 
> in PROV-N, has:
> [...]
>
> #g
> -- 
>
> On 28/06/2012 15:41, Luc Moreau wrote:
>> Hi James,
>>
>> Thanks for summing up the situation.
>>
>> I have reverted specializationOf back to its original definition.
>>
>> I have introduced the concept Mention (as a proposed renaming for
>> contextualization)
>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-mention 
>>
>>
>> For reference, I have kept the text of contextualizationOf as it was 
>> at the time
>> of F2F3.
>>
>> Cheers,
>> Luc
>>
>> On 06/28/2012 03:34 PM, 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...
>>>
>>>
>>>> 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
>>>
>>> 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)
>>>
>>> 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")
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> But, your suggestion of using another term from DC seems sensible as 
>>> a stopgap
>>> (perhaps this suggestion could go into the DC mapping document too).
>>>
>>> --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
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>

Received on Thursday, 28 June 2012 19:15:08 UTC