Re: ISSUE-385: hasProvenanceIn: finding a solution

Hi Tim,
If they go in prov-o, then we also want them in prov-dm, prov-xml, etc
Luc

On 06/06/2012 02:18 PM, Timothy Lebo wrote:
> So, Luc and PAQ'ers:
>
> Are we covered, if PROV-O had the 5 PAQ terms?
>
> -Tim
>
> On Jun 6, 2012, at 6:47 AM, Paul Groth wrote:
>
>    
>> Hi Luc,
>>
>> I would say that this attributes should not be a part of the dm. If
>> they are defined, these should be part of the paq. This not mean that
>> should not be possible to include as attributes on bundles.
>>
>> I think the key is to identify the bundle not necessarily convey how
>> to obtain it.
>>
>> Thanks
>> Paul
>>
>> On Wed, Jun 6, 2012 at 12:12 PM, Luc Moreau<L.Moreau@ecs.soton.ac.uk>  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.
>>>
>>> So, two questions:
>>>
>>> 1. Do we define these as part of the prov-dm/prov-o?
>>>
>>> 2. Can they be defined as optional attributes of bundles?
>>>
>>> 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", but
>>> it is more useful if it is a rdfs:Resource<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 Kingdom                     http://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
>>>        
>>
>>
>> -- 
>> --
>> Dr. Paul Groth (p.t.groth@vu.nl)
>> http://www.few.vu.nl/~pgroth/
>> Assistant Professor
>> Knowledge Representation&  Reasoning Group
>> Artificial Intelligence Section
>> Department of Computer Science
>> VU University Amsterdam
>>
>>
>>      
>    

-- 
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:49:01 UTC