Re: Contextualization ---> Optional bundle in Specialization

Hi Graham,

If provenance had been written as below, we wouldn't need
contextualization for this rating example.  ex:Bob would be the
general entity, and tool:Bob-2011-11-16 and tool:Bob-2011-11-17 its
specializations, for each activity involvement on different days.


// MORE PROPER

    bundle ex:run1
         activity(ex:a1, 2011-11-16T16:00:00,2011-11-16T17:00:00) 
    //duration: 1hour
         specializationOf(tool:Bob-2011-11-16, ex:Bob)
        
    wasAssociatedWith(ex:a1,*tool:Bob-2011-11-16*,[prov:role="controller"])
    endBundle


    bundle ex:run2
         activity(ex:a2, 2011-11-17T10:00:00,2011-11-17T17:00:00) 
    //duration: 7hours
         specializationOf(tool:Bob-2011-11-17, ex:Bob)
        
    wasAssociatedWith(ex:a2,*tool:Bob-2011-11-16*,[prov:role="controller"])
    endBundle



It's because we allow identifiers to be reused, and we allow
provenance to be "messy", that the following is accepted in PROV.


// MORE SCRUFFY

    bundle ex:run1
         activity(ex:a1, 2011-11-16T16:00:00,2011-11-16T17:00:00) 
    //duration: 1hour
         wasAssociatedWith(ex:a1,*ex:Bob*,[prov:role="controller"])
    endBundle

    bundle ex:run2
         activity(ex:a2, 2011-11-17T10:00:00,2011-11-17T17:00:00) 
    //duration: 7hours
         wasAssociatedWith(ex:a2,*ex:Bob*,[prov:role="controller"])
    endBundle


If provenance is to be used online by applications to make decisions,
I don't understand what the problem is with the following


     specializationOf(tool:Bob-2011-11-16, ex:Bob, ex:run1) // or 
contextualizationOf, or whatever name we want

given that it could have been written in the first place if provenance
had been more proper.

Your comment that tool:Bob-2011-11-16 cannot be distinguished from 
tool:Bob-2011-11-17 would also
apply to the more proper example.

Regards,

Luc


On 06/27/2012 06:09 PM, Graham Klyne 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
>>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm