Re: ISSUE-385: hasProvenanceIn: finding a solution

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

Received on Wednesday, 6 June 2012 10:48:28 UTC