Re: ISSUE-385: hasProvenanceIn: finding a solution

Hi Tim

You do have inContext from Entity to Context, don't you?

I would encode the rdf below in prov-dm as follows:


contextualizationOf(anonymous, ex:Bob, ex:run2)

alternateOf(tool:Bob2,  anonymous )

Does it make sense?

Luc

Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom

On 6 Jun 2012, at 17:52, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:

Luc,

Some more thoughts on the proposal.

I think an important aspect of our email drafts (shown below) was that no new RDF property was created between the entity and the bundle:

=====
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?
       ];
}
=====


By http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd6-contextualization.html 's :


bundle tool:analysis01

 contextualizationOf(tool:Bob1, ex:Bob, ex:run1)

endBundle


do you mean (or, may I [still] interpret as):


tool:analysis01 {
    tool:Bob1
        prov:specializationOf [
              a prov:Entity;  prov:ContextualizedEntity;
              prov:identifier  ex:Bob;
              prov:inContext ex:run1;
        ];
    .
}


is it also true that there will never be a PROV-O statement that reflects DM that looks like:

?a  prov:contextualizationOf ?b .

(i.e., that prov:contextualizationOf does not exist).


Thanks,
Tim







On Jun 6, 2012, at 6: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<mailto:l.moreau@ecs.soton.ac.uk>
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm