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

Re: ISSUE-385: hasProvenanceIn: finding a solution

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Wed, 06 Jun 2012 14:46:56 +0100
Message-ID: <EMEW3|f98f1ab8e8ae79bafa4651fcd1fcf0eao55Ekw08L.Moreau|ecs.soton.ac.uk|4FCF5F50.1080606@ecs.soton.ac.uk>
To: Timothy Lebo <lebot@rpi.edu>
CC: W3C provenance WG <public-prov-wg@w3.org>
Hi Tim,

Here there are:

http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-attribute-provenance-uri
http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-attribute-service-uri

Yes, they could be applied to any term of the data model.

Luc

On 06/06/2012 02:17 PM, Timothy Lebo wrote:
> Luc,
>
> On Jun 6, 2012, at 6:12 AM, Luc Moreau wrote:
>
>> Hi Tim,
>>
>> The last point now is that in the original proposal, we
>> had some optional attributes prov:service-uri and prov:provenance-uri.
>
> I'm not sure how you want to use them.
> Where should I see these discussed w.r.t. contextualization?
> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd6-contextualization.html
>
>
>
>>
>> So, two questions:
>>
>> 1. Do we define these as part of the prov-dm/prov-o?
>
> PAQ's 5 were added to PROV-O yesterday: 
> http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html#names-added-to-prov--namespace
>
> Are your attributes within those 5 (specifically, hasProvenance and 
> hasProvenanceService)?
> Or are they different?
>
>>
>> 2. Can they be defined as optional attributes of bundles?
>
> min 1 cardinality violates RL, and we have been avoiding those kinds 
> of assertions.
> I have yet to read through the PAQ in depth. Should prov:hasProvenance 
> and hasProvenanceService have domains of Bundle? (that would mean that 
> anything that used these properties is a bundle). That seems too 
> constrained to me.
>
>
> -Tim
>
>
>>
>> Cheers,
>> Luc
>>
>> On 06/06/2012 11:10 AM, Luc Moreau wrote:
>>> Hi Tim,
>>>
>>> See below.
>>>
>>> On 06/05/2012 11:26 PM, Timothy Lebo wrote:
>>>> Overall, looks pretty good.
>>>>
>>>>
>>>
>>> Great, it looks like we are converging.
>>>>
>>>>
>>>> "sharing the facets"
>>>> ->
>>>> perhaps use "presenting aspects" as with the accepted phrasing from 
>>>> the last round of alt/spec definitions?
>>>>
>>>
>>> Yes,
>>>>
>>>> BTW, you still have a missing 0 in:
>>>> 2011-11-16T16:00:00,2011-11-16T17:0:00
>>>>
>>>>
>>> fixed
>>>>
>>>> "A new agent tool:Bob1 is declared as a restriction of ex:Bob"
>>>> -> ?
>>>> "A new agent tool:Bob1 is declared as a specialization of ex:Bob"
>>>>
>>>
>>> I used contextualization to avoid confusion with the 
>>> specializationOf relation.
>>>>
>>>>
>>>> "defines two specializations of these contextualized agents with 
>>>> associated rating"
>>>> -> (nit)
>>>> "defines two specializations of these contextualized agents with an 
>>>> associated rating"
>>>>
>>>>
>>>> "bade" -> "bad"
>>>
>>> Fixed.
>>>
>>>>
>>>>
>>>>
>>>> I'm finally comfortable with your modeling of the visualization 
>>>> scenario.
>>>>
>>>>
>>>
>>> Great.
>>> Question: in the second example, is it appropriate to write
>>>
>>>   entity(tool:report1, [viz:color="orange"])         // is it 
>>> appropriate to add viz attributes to tool:report1 or should we 
>>> specialize it?
>>>
>>>
>>> or should we have two separate entities
>>>
>>>
>>>     entity(tool:report1)
>>>     entity(tool:specializedReport1, [viz:color="orange"])
>>>     specializationOf(tool:specializedReport1, tool:report1)
>>>
>>>
>>> Luc
>>>
>>>> -Tim
>>>>
>>>>
>>>>
>>>> On Jun 5, 2012, at 4:03 PM, Luc Moreau wrote:
>>>>
>>>>> Hi Tim,
>>>>>
>>>>> I tried to write this up as a separate relation 
>>>>> contextualizationOf, see section 1.3 in [1].
>>>>> I believe this relation is compatible with your rdf encoding. The 
>>>>> only difference, here,
>>>>> is that we make this an identifiable thing.
>>>>>
>>>>>        [
>>>>>            a prov:Entity;  prov:ContextualizedEntity;
>>>>>            prov:identifier       ex:Bob;
>>>>>            prov:inContext     ex:run2;
>>>>>        ];
>>>>>
>>>>> What do you think?
>>>>> Luc
>>>>>
>>>>> [1] 
>>>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd6-contextualization.html
>>>>>
>>>>> On 04/06/2012 23:25, Timothy Lebo wrote:
>>>>>> Luc,
>>>>>>
>>>>>> (bottom)
>>>>>>
>>>>>> On Jun 4, 2012, at 5:31 PM, Luc Moreau wrote:
>>>>>>
>>>>>>> Hi Tim,
>>>>>>>
>>>>>>> Some comments/questions below.
>>>>>>>
>>>>>>> On 04/06/2012 13:46, Timothy Lebo wrote:
>>>>>>>> Luc,
>>>>>>>>
>>>>>>>> On Jun 4, 2012, at 5:16 AM, Luc Moreau wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> During this diamond jubilee WE, I had the opportunity to think 
>>>>>>>>> about Tim and Simon's long emails.
>>>>>>>>>
>>>>>>>>> I agree with them that we have concepts of alternate and 
>>>>>>>>> specialisation, and we want to reuse them.
>>>>>>>>>
>>>>>>>>> I also came to the conclusion that behind the hasProvenanceIn 
>>>>>>>>> relation, what I really wanted was a form of alternate. But 
>>>>>>>>> not what Tim or Simon are suggesting.
>>>>>>>>>
>>>>>>>>> The PROV data model has a shortcoming: the inability to 
>>>>>>>>> identify something in some context. That's what I am trying to 
>>>>>>>>> address here.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 
>>>>>>>>
>>>>>>>>
>>>>>>>>> The interpretation of
>>>>>>>>>        alternate(tool:Bob2, ex:Bob,ex:run2)
>>>>>>>>> is that tool:Bob2 is the entity that share aspects of ex:bob 
>>>>>>>>> as described by ex:run2. *Conceptually*, this could be done by 
>>>>>>>>> substituting ex:Bob for tool:Bob2 in ex:run2.
>>>>>>>>>
>>>>>>>>> I appreciate that what I am describing here is not too distant 
>>>>>>>>> from 
>>>>>>>>> http://www.w3.org/TR/2011/WD-prov-dm-20111215/#record-complement-of, 
>>>>>>>>> which had optional account, and was not received with 
>>>>>>>>> enthusiasm, to say the least.
>>>>>>>>>
>>>>>>>>> Coincidentally, Paul shared this paper
>>>>>>>>> http://ceur-ws.org/Vol-614/owled2010_submission_29.pdf which 
>>>>>>>>> introduces  rules of the kind
>>>>>>>>> /X counts as Y in context C/
>>>>>>>>> which bears some resemblance with what I am trying to argue for.
>>>>>>>>>
>>>>>>>>> So, my proposal is;
>>>>>>>>> - drop hasProvenanceIn
>>>>>>>>> - drop isTopicIn
>>>>>>>>> - allow for the ternary form of alternate
>>>>>>>>>
>>>>>>>>> Tim and Simon approach by using two binary relations do not 
>>>>>>>>> offer the same level of expressivity.
>>>>>>>>> The also have a technological bias, as well: they require 
>>>>>>>>> querying/reasoning facility.  Therefore,
>>>>>>>>> their suggestion is not suitable for a data model supposed to 
>>>>>>>>> be technology neutral.
>>>>>>>>
>>>>>>>>
>>>>>>>> A stab at:
>>>>>>>>
>>>>>>>> bundle tool:analysis01
>>>>>>>>      alternate(tool:Bob2, ex:Bob,ex:run2)
>>>>>>>> endBundle
>>>>>>>>
>>>>>>>> in PROV-O:
>>>>>>>>
>>>>>>>> tool:analysis01 {
>>>>>>>>     tool:Bob2
>>>>>>>>        prov:alternateOf [  ## The use here of bnode is, for 
>>>>>>>> once, actually appropriate :-)
>>>>>>>>            a prov:Entity;  prov:ContextualizedEntity;
>>>>>>>>            prov:identifier       ex:Bob;   ## The identifier 
>>>>>>>> that is used "over there"   Can't use dcterms:identifier b/c 
>>>>>>>> that is a rdfs:Literal.
>>>>>>>>            prov:inContext     ex:run2;   ## "over there"       
>>>>>>>> Could prov:atLocation be reused?
>>>>>>>>        ];
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> Thanks for this, Tim.
>>>>>>>
>>>>>>> First some questions:
>>>>>>> - why a bnode here?
>>>>>>
>>>>>> bnodes are read "the thing that" and _can_ serve as an existential.
>>>>>>
>>>>>>> - Can you explain the  dcterms:identifier comment?
>>>>>>
>>>>>> 1) The value is the identifier used in the other bundle.
>>>>>> 2) The rdfs:range of dcterms:identifier is a literal 
>>>>>> "http://foo.com <http://foo.com/>", but it is more useful if it 
>>>>>> is a rdfs:Resource <http://foo.com <http://foo.com/>>. With the 
>>>>>> former, we know that we can "try to go there" to dereference the URI.
>>>>>>
>>>>>>>
>>>>>>> Now, assuming that this rdf encoding expresses what was 
>>>>>>> originally suggested, some further questions:
>>>>>>> - have we got indeed a ternary alternateOf relation in prov-dm 
>>>>>>> as I suggested?
>>>>>>
>>>>>> Perhaps. The original binary that we now know and love, and a 
>>>>>> second ternary that "wraps" a URI and a Bundle (that mentions the 
>>>>>> URI).
>>>>>> The only new things would be:
>>>>>>
>>>>>> 1) The two new predicates prov:identifier and prov:inContext 
>>>>>> (perhaps that should just be called prov:inBundle -- I was swayed 
>>>>>> too far towards DCTerms when I chose that this morning).
>>>>>> 2) The new rule to unwrap your ternary DM into this RDF structure.
>>>>>>
>>>>>>
>>>>>>> - or have we got some form of ternary relation 
>>>>>>> isContextualizationOf(e2,e1,bundle)?
>>>>>>
>>>>>> Or, just a binary isContextualized(e1,bundle)?
>>>>>>
>>>>>> And we just stack on an existing alternateOf(e2,e1)...
>>>>>>
>>>>>>
>>>>>> BTW, not really sure where we're going with this.
>>>>>> It feels like we're close to wrapping this up, but worried that 
>>>>>> we're in some odd local minima.
>>>>>>
>>>>>> Regards,
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Luc
>>>>>>>
>>>>>>
>>>>
>>>
>>> -- 
>>> 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 Kingdomhttp://www.ecs.soton.ac.uk/~lavm
>>>    
>>
>> -- 
>> 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 Kingdomhttp://www.ecs.soton.ac.uk/~lavm
>>      
>

-- 
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
Received on Wednesday, 6 June 2012 13:47:34 UTC

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