Re: Contextualization ---> Optional bundle in Specialization

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 17:55:26 UTC