Provenance Working Group Teleconference -- 07 Jun 2012

<trackbot> Date: 07 June 2012

<pgroth> I need a scribe

<pgroth> anyone?

<pgroth> scribe anyone?

<pgroth> tom can you scribe?

noone signed up?

sure

<pgroth> no :-(

<pgroth> thanks

np: )

<pgroth> Scribe: Tom De Nies

<Luc> @paul, we need to draft the f2f2 agenda

<pgroth> @luc: yes. next week I'm "on vacation" visiting parents so will have time

<Luc> @paul: OK

sorry, phone dropped off for a second there

<stain> I'm in a meeting like GK and dgarijo, but I'll join when/if you come to collection

Admin

<stain> and follow the hasProvenanceIn discussion on the chat

<pgroth> http://www.w3.org/2011/prov/meeting/2012-05-31

<pgroth> proposed Minutes of the May 31 2012 Telecon

<SamCoppens> +1

<dgarijo> +1

<Curt> +1

<jcheney> 0 - missed it

<smiles> +1

<Paolo> 0 -- missed it

<pgroth> approved: Minutes of the May 31 2012 Telecon

<pgroth> sandro are you there?

pgroth: we confirmed that sandro sent the announcement to the mailing lists, and Graham has reviewed the constraints document

Definition of role

pgroth: to summarize: we talked last week about expanding the definition of role
... We tried to come to a revised definition during the week, that included both the object and subject of role
... No apparent consensus was reached

smiles: In my email, I wasn't suggesting that we would drop 'role' and just have 'type'.
... I would propose keeping what we had, I liked the definition of role

pgroth: What do you think about expanding the domain of role?

smiles: I don't have a strong objection to it, but I'm not quite sure what it imply

Luc: Simon's suggestion seems good. We could keep the current definition and make sure all documents are compatible with it
... Would it cause a problem if you could not use roles in the Dictionary context?

tlebo: I would have to have an extention property

<Paolo> no objection

pgroth: I think people just wanted to make role a bit more powerful, but were fine with the definition. Is there any objection to leaving role as it is?

<Luc> @paul, for avoindance of doubt, can you record a resolution?

<pgroth> proposed: leave role as currently defined

<KhalidBelhajjame> +1

<satya> +1

<Paolo> +1

<jcheney> 0 - haven't been following but no objection

<SamCoppens> +1

<smiles> +1

<MacTed> +0

<CraigTrim> no objection

<pgroth> accepted: leave role as currently defined

Contextualization

pgroth: Luc, can you give an overview?

Luc: About a week ago, GK raised an issue that the provenance locator was too complex.
... Reasons: Prov locator included things from the PAQ that would better not be mixed with the DM. THis was solved by removing these from the DM.

<pgroth> @sandro are you there?

Luc: A second objection was that it seemed as a special case of derivation, and it might be better to use things that we already have.

<Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd6-contextualization.html

Luc: We looked at this during the weekend, and came up with above.

<Luc> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd6-contextualization.html#term-contextualization

Luc: The idea is that a relation can be introduced that says that some thing is a contextualization of another thing.
... Something that is a contextualization of another presents all aspects of the latter in a given context specified by descriptions found in a bundle.
... Discussion with tim and simon seems to be reaching consensus.
... In time, the provenance locator would disappear from prov DM, and the contextualization remains

pgroth: how does this relate to alternate/specialization?

Luc: difference with specialization is that contextualization looks at the aspects in a given context (bundle)

smiles: At the moment it is a bit ambiguous
... I suggest expressing contextualization as a relation between entity and bundle

<Luc> i couldn't understand simon

smiles: I don't have a problem with the current definition of contextualization, but changing the relationshi
... to an entity-bundle relationship might help distinguishing it from specialization

<tlebo> contextualization is the specialization of a "nonlocal" entity by "fixing" the bundle that it is in. Once this is done, one can then use specialization _again_ to link a "local" entity to a "nonlocal" entity.

paolo: Is this as in importing provenance from a different bundle?
... saying that "everything I say in that bundle about this entity, is also true in this bundle"

<Luc> 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

<pgroth> http://dvcs.w3.org/hg/prov/raw-file/default/model/working-copy/wd6-contextualization.html

Luc: I think so (see example)

Paolo: this is close to what I had in mind

Luc: it is not really "importing"
... That is an implementation choice, but it is not specified anywhere.

<Paolo> ack

smiles: In the current DM, we say that a bundle is a set of descriptions. There's no reason for that set not to be contradictory with other sets.
... My concern is that with this contextualization, we seem to suggest that there is some sort of coherence.

<pgroth> +q

Luc: It's not our aim to imply any consistency

smiles: OK, but then we should specify this clearly.

tlebo: proposes the above definition.

pgroth: 1. How core is it to the model? 2. Are we close to a definition?

Luc: There are examples of where we need this construct. And currently there is no way to assert them.

<tlebo> BTW, my definition is paired up with the example that I focus on: tool:analysis01 { tool:Bob1 prov:specializationOf [ a prov:Entity; prov:ContextualizedEntity; prov:identifier ex:Bob; prov:inContext ex:run1; ]; . }

Luc: I like Tim's definition, and can agree with Simon's suggestion. We hope to converge within a few days.

<tlebo> bundles don't change.

satya: What happens if the bundle is changed after a contextualization?
... Does this propagate?

<tlebo> +1 @luc, if the bundle changes, then you have a new bundle.

Luc: If a bundle changes, it is another bundle

satya: So there is no way that we will link those "updated" bundles?

<tlebo> @satya, link a revised bundle to it's predecessor via PROV constructs specializationOf and wasRevisedFrom .

satya: (as is often done in the Semantic Web)

<tlebo> bundles are not buckets, they are sets of assertions.

<tlebo> we have ways to link the bundles -- existing PROV constructs.

@satya: indeed, the assertions don't change, just the bundle

Luc: See Tim's comment.
... I don't think we changed the semantics with this construct.
... If you change a set of assertions, you need to give it a different name.

<satya> agent(tool:ratedBob1, [perf:rating="good"])

Luc: It seems the concern is rather to the notion of bundle, than to contextualization?

satya: yes

<tlebo> @satya where is "bundle consistency" proclaimed in PROV? bundles are just sets of assertions, regardless of consistency.

<tlebo> bundling assertions does not imply consistency.

satya: Since it is included as an example with the definition, it seems to someone reading the definition without knowing the discussion, that we are implying some semantics

pgroth: Since there seems to be some convergence to this construct, we should try to work toward a definition everyone agrees with via the mailing list

Collections

<Paolo> (I'm afraid I am a lot more confused about this now than I was 1/2 hour ago...)

pgroth: Tim proposed some changes to Collections

http://lists.w3.org/Archives/Public/public-prov-wg/2012Jun/0133.html

tlebo: only changes that affect the DM:
... - the notion of complete collection
... This optional attribute would be removed and changed to a domain extention
... This is based on several concerns received about 'complete' Collections
... in an open world

Luc: Something more fundamental needs to be discussed...
... Currently, we have a notion of empty Collection/Dictionary
... and a notion of insertion
... If you start with an empty Dictionary, and insert something, you have full knowledge about the Dictionary
... Dito for removal
... What we call a 'complete membership' when you are inserting into an empty Dictionary.
... The normal memberOf was added to allow insertion into an unspecified Dictionary

<tlebo> FWIW, my work on Dictionary was centering around the example at http://www.w3.org/2011/prov/wiki/Eg-34-us-supreme-court-membership and http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl

pgroth: There's a difference between asserting that something is closed, and the thing actually being closed.

<tlebo> +1 pgroth

<tlebo> I'm using Paul's former to agree with keeping "completeness" in (asserting that something is closed). I'm ignoring his latter (the thing actually being closed).

(could you put your question on IRC stain? (sorry, missed it))

<stainPhone> Ok

Luc: what the model allows it that if you inserted e1 in d1, and that lead to d2.
... you can still have that you insert something into d1, and that becomes d3

pgroth: What is the conflict of what Tim proposes and the current DM?

<stainPhone> I asked if dictionary insertions and removals are strictly functional, or if you could have both wasInsertedFrom(a,b,(k1,v1)) and second wasInsertedFrom(a,b,(k2,v2)) with additional key value pair

<stainPhone> Luc said that no, only one assertion. (right?)

Luc: not much. If we drop the attribute, we can still assert everything. We have the same expressivity

<KhalidBelhajjame> Yes Paolo, I remember the initial discussion

<tlebo> FWIW, I've catalyzed this proposal for a variety of people. I've personally withdrawn my objections, but haven't heard others continuing to object.

Paolo: This seems to go back to a previous discussion we had about the Open World assumption, and why we introduced the notion of completeness in the first place

<tlebo> yes, so I don't see anybody objecting.

<stainPhone> Who are they?

<Luc> who was objecting?

pgroth: does anyone object to leaving it as it is now?

(silence)

<stainPhone> I'll pay them a visit! ;)

pgroth: Maybe we should just put somewhere: "You can assert completeness, but you can never guarantee it"

<tlebo> +1 paul, we're asserting it and not guaranteeing it. This is what resolved my objection.

<pgroth> ACTION: Luc to add some text around collections to clarify completness [recorded in http://www.w3.org/2012/06/07-prov-minutes.html#action01]

<trackbot> Created ACTION-91 - Add some text around collections to clarify completness [on Luc Moreau - due 2012-06-14].

Luc: will add some text for this.

<Paolo> well can you guarantee anything in provenance that you can express??

<KhalidBelhajjame> bye

no prob :)

<pgroth> thanks tom

<SamCoppens> bye

<tlebo> bye!

@ Paolo: id say no, then it'd be called Trust

<pgroth> trackbot, end telcon

- DRAFT -

Provenance Working Group Teleconference

07 Jun 2012

Attendees

Contents

Admin

Definition of role

Contextualization

Collections

Summary of Action Items

Scribe.perl diagnostic output