- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Thu, 12 Jul 2012 10:26:49 +0100
- To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>, Timothy Lebo <lebot@rpi.edu>
Stian,
Yes, I suggest hadMember(c,e).
James in a separate email suggested a way of defining a new
membership class as a kind of derivation:
For instance, wasDerivedFrom(c,e,[prov:type='my:Membership'])
or even using prov-n syntax extensibility
my:hadMember(c,e,[prov:label="what a beautiful membership"])
Luc
On 07/12/2012 10:10 AM, Stian Soiland-Reyes wrote:
> Short response - I don't feel strongly for membership to be qualified
> (in PROV-O) and have attributes/id/type (in DM), but would have
> preferred it to be there for extension purposes. Given the time frame
> I am reluctantly not protesting. (a -0 vote if you like)
>
>
> Could you draft what is your suggested new PROV-N syntax? I am
> wondering which of these you are proposing:
>
> hadMembers(membership1, c, {e1, e2, e3}, true) // Drop attributes
>
> hadMembers(c, {e1, e2, e3}, true) // Drop attributes and statement ID
>
> hadMembers(c, {e1, e2, e3}) // Drop completeness (!!)
>
> hadMember(c, e1) // Drop entity set
> hadMember(c, e2)
> hadMember(c, e3) // ..now it looks like a subtype of wasInfluencedBy
>
>
>
> I can see that as collection is a general structure, it can be really
> useful for applications to subtype and extend the membership. In
> PROV-O it is of course possible to create subproperties, but we would
> generally recommend subclassing an Influence class instead, like
> making "physics:Fusion" a subclass of "prov:Derivation", allowing
> additional attributes in the subclass. Making membership a binary
> relationship breaks this pattern. In PROV-DM it would not be possible
> to express any custom membership - for instance to provide
> meta-provenance or annotations about how the membership was observed,
> give a particular characterization to a subset of a collection, etc.
>
> I know that the current PROV-O solution (which I have not had time to
> influence lately) unrolls the membership per entity - although the
> examples there need updating, you can't any more in PROV-O reflect the
> ID and attributes of a hadMembers() statement in PROV-N with multiple
> entities in the set. So it would need to go one way or the other to
> make it consistent.
>
>
> I can also see an argument that it is an observational thing, like
> specializationOf and alternateOf - which don't have statement
> identifier nor attributes.
>
> So as short - reluctant OK for the simplification - but I'm sad to see
> the extensibility mechanism be lost. I can see that this makes it more
> difficult to make extensions like the note PROV-Dictionary, as I would
> have to make my own, disconnected DictionaryMembership that can
> reflect the dictionary key, rather than just adding it as an attribute
> to a specialized prov:Membership/hadMembers().
>
>
>
> My earlier response to a private email below:
>
>
> On Wed, Jul 11, 2012 at 11:23 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:
>
>> When reviewing the latest prov-o Membership I came across a misalignment
>> between prov-dm and prov-o. Membership is not Influence in prov-dm, but
>> is Influence in prov-o.
>>
>> If membership is a derivation then we are OK. But some in the group didnt
>> want this.
>
> I agree that membership is not (necessarily) a derivation. A
> membership statement is just an observation, it is not expressing how
> the two activities are formed. However, given that a characterisation
> of a collection is static within PROV, then its constituent members
> must have been generated before or at the same time as the collection.
> Thus it is another case of 'traceTo' in my mind - and so it is an
> influence.
>
> A derivation is a strong statement, because in DM we require the
> derived from entity to be directly involved with the activity that
> created the derived entity. We don't know at what stage the entity got
> added, as the collection {e1,e2,e3} could have been formed by removing
> d from {e1,e2,e3,e4}.
>
> However we know that at some point there must have been an (implied)
> activity that used e1 and generated a collection that contained e1 -
> and that the current collection has a trace of derivations leading
> back to these two. Thus we are talking about here is the transitive
> derivation - basically wasInfluencedBy towards every entity in the
> entity set.
>
>
> if e1 is a member of collection c1, then e1 influences c1 - because if
> e1 was not there, c1 would have been different. Or in another way - e1
> is a requirement for c1 to be made.
>
> This sounds just like any other influence.
>
> " Influence ◊ is the capacity of an entity, activity, or agent to have
> an effect on the character, development, or behavior of another by
> means of usage, start, end, generation, invalidation, communication,
> derivation, attribution, association, or delegation."
>
> Well, if this definition is to list every subclass (basically like an
> OWL equivalent class of the union of the subclasses) and do not allow
> any other kind of influencing, then it simply needs to include
> membership as well. That should not be a problem as membership is part
> of DM.
>
>
>
>> With Tim, I explored a number of solutions, including making it a non qualified
>> relation: i.e. a binary hadMember(collection,entity), no complete flag, no identification,
>> no permitted subtype in prov-dm.
>
> I suggest keeping it as it is, as I don't see a problem with it being
> an influence. I think the qualified membership could be essential when
> I get down to tidying up the Dictionary note so that it is a proper
> extension of PROV-DM and PROV-O.
>
>
> Another solution for PROV-O would be to introduce a superclass of
> Influence that is "Qualified". This would become another abstract
> class for a single purpose, which introductions have not been popular
> within the task force. I even think we had "Qualified" earlier - and
> it was much appreciated that now we have classes that almost all make
> sense provenance wise and which relate to PROV-DM.
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
>
>
> On Thu, Jul 12, 2012 at 9:26 AM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
>> Dear all, Tim,
>>
>> After sleeping on this issue, I think there is only one workable outcome:
>> Membership should be a binary relation without associated qualified class.
>>
>> Context: after F2F3, Dictionaries were dropped from prov-dm, but the n-ary
>> membership relation was kept:
>> hadMembers(mId, c, {e1, e2, e3}, true, [prov:label="A beautiful
>> collection"])
>>
>> Recently, Tim re-introduced this relationship in prov-o as a form of
>> Influence.
>> There was some push back for membership to be a kind of Derivation. Making
>> it Influence
>> and not Derivation would suddenly introduce a new relation in the model we
>> don't
>> understand the implications. Not making it an Influence would break the
>> prov-o design.
>>
>> Some reviewers had suggested to make it binary. It seems it is the right
>> choice, in
>> the circumstances, as the minimum we can agree on, given such a short time.
>>
>> So, I will implement the changes very shortly. Please should if there is a
>> problem.
>> Tim, ..., sorry to ask, can you revert back to a binary hadMember without
>> associated
>> class?
>>
>> Luc
>>
>>
>>
>> On 07/11/2012 11:15 PM, Luc Moreau wrote:
>>
>> Hi Tim,
>>
>> We have a number of possibilities for qualified Membership. None
>> seems particularly good.
>>
>> 1. Membership is an Influence and a Derivation.
>> Some F2F3 participants seemed to be against membership as
>> derivation.
>>
>> 2. Membership is an Influence and not a Derivation
>>
>> I feel that this is not realistic. To me, all forms of influence
>> between two entities are derivations.
>>
>> It would also be surprising that a concept that was about
>> to be dropped from the provenance model, is in fact a primitive
>> form of influence, not expressible differently.
>>
>> 3. Membership is still qualified, but not an Influence.
>> This would break the prov-o design consistency.
>>
>> 4. Membership should not be qualified.
>> Some wanted to keep it qualified.
>>
>> 5. ... drop membership ... timeout!
>>
>> Luc
>>
>>
>> On 11/07/12 21:54, Timothy Lebo wrote:
>>
>> Luc,
>>
>> On Jul 11, 2012, at 4:49 PM, Luc Moreau wrote:
>>
>> Hi Tim,
>>
>> Thanks for the updated membership.
>>
>> We do have misalignment between provo and prov-dm.
>> And I don't know how to solve it.
>>
>> In prov-dm, membership is not a subtype of influence.
>> I recall explicitly some F2F3 participants didn't want membership as
>> a form of derivation. I am not sure what their view would be about
>> influence.
>>
>> If the group agrees that membership *is* a kind of influence,
>>
>>
>> I think it's reasonable to say that an element of a set influences the set.
>>
>> I don't know
>> where Influence should go in prov-dm, since it would no longer belong to
>> component 3.
>>
>> If the group decides that membership *is* not a kind of influence, can you
>> still
>> express Membership using the qualified pattern ... without influence?
>>
>>
>>
>> To do so will lose a lot of design consistency.
>>
>>
>>
>> Hhhhmmm?
>>
>> What ever the decision ... more editing in perspective :-(
>> Sorry about that.
>>
>>
>> :-/
>>
>> -Tim
>>
>>
>> Luc
>>
>>
>>
>>
>>
>> On 11/07/12 18:15, Timothy Lebo wrote:
>>
>> prov-wg,
>>
>> http://aquarius.tw.rpi.edu/prov-wg/prov-o
>>
>> now has the qualified membership terms (I added IncompleteCollection, which
>> we haven't discussed before).
>>
>>
>> The ontology in it's usual place:
>>
>> http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/ProvenanceOntology.owl
>>
>>
>> The examples need to be reviewed and updated. Any pointers to flaws would be
>> appreciated.
>>
>>
>> Regards,
>> Tim
>>
>>
>> On Jul 11, 2012, at 9:38 AM, Luc Moreau wrote:
>>
>>
>>
>> send a link and I'll try to look at it later today
>>
>> On 11/07/2012 14:31, Timothy Lebo wrote:
>>
>>
>> Luc,
>>
>> I put qualified membership back into the OWL file.
>> I need to regenerate the HTML and will check through the update today.
>>
>> If you can take a look and provide any early feedback, I'd appreciate it.
>>
>> Regards,
>> Tim
>>
>> On Jul 9, 2012, at 8:58 AM, Luc Moreau wrote:
>>
>>
>>
>>
>> Hi Tim
>>
>> I understood [1] as take the 'dictionary' concepts and move them in a
>> separate document,
>> and keep the rest unchanged. We had just been through a round of
>> discussion, for
>> which there seems to be agreement on Collection, EmptyCollection and the
>> membership
>> as currently described in the dm.
>>
>> I agree though that it is a good idea to change the name to hadMembers or
>> similar.
>>
>> Regards,
>> Luc
>>
>>
>>
>> [1] http://www.w3.org/2011/prov/meeting/2012-06-22#resolution_2
>>
>> ________________________________________
>> From: Timothy Lebo [lebot@rpi.edu]
>> Sent: Monday, July 09, 2012 1:39 PM
>> To: Luc Moreau
>> Cc: public-prov-wg@w3.org
>> Subject: Re: PROV-ISSUE-444 (prov-o-to-last-call): Review PROV-O for last
>> call [PROV-O HTML]
>>
>> Luc,
>>
>> On Jul 9, 2012, at 4:05 AM, Luc Moreau wrote:
>>
>>
>>
>>
>> ... and no qualified form for membership.
>>
>> Dont' we want subtyping and identification ?
>>
>>
>>
>> I never got the impression that qualified membership was part of what
>> "stayed in" during our F2F vote.
>> We continually said "Collection and hadMember", and never mentioned
>> "qualifiedMembership and Membership".
>>
>> So, what was the intent of the group?
>>
>> Or, does DM intrinsically connect these and I just misinterpreted?
>>
>> Thanks,
>> Tim
>>
>>
>>
>>
>> Luc
>>
>> On 07/09/2012 09:02 AM, Luc Moreau wrote:
>>
>>
>>
>> Hi prov-o team,
>>
>> It seems there is another non-alignment between prov-o and prov-dm.
>> Isn't there a prov:EmptyCollection class in the ontology?
>>
>> Luc
>>
>>
>> On 07/04/2012 03:02 PM, Luc Moreau wrote:
>>
>>
>>
>> Hi prov-o team, again,
>>
>> Find below some specific comments about the provo document.
>>
>>
>> Thanks for the extensive work!
>> It needs some polishing, but the majority of it, can happen after LC.
>>
>> Answer to your questions:
>>
>> 1) Are there any issues that should delay the WG's release of PROV-O as Last
>> Call (i.e., is all of the technical work done).
>>
>> - Minor Issues in the ontology raised in my previous message
>> - Definition alignment, and make sure that example don't use constructs
>> incorrectly (e..g hadRole)
>>
>> 2) Are the examples and scenario adequate?
>>
>> - Yes, though I couldn't follow the scenario anymore without a picture. Can
>> a picture be added, with the style adopted by other documents
>>
>> 3) Should the links to prov-dm, prov-constraints, and prov-n stay in the
>> cross reference?
>>
>> - See comment below.
>>
>>
>>
>> Specific comments:
>>
>> Section 1
>> - owl-rl -> orl-rl ++
>> - para 3: provdm introduces a MINIMAL set of concepts ... delete MINIMAL
>> - "... which facilitate a fixed interpretation and use of the prov data
>> model concepts based on the formal semantics of owl2: " delete
>> - reference to xml-schema should be to xml-schema11 (owl2 automatically
>> switched to xml-schema11)
>>
>> section 2:
>> - "the terms in this category ARE APPLIED IN the same way ..." not sure what
>> this mean.
>>
>> section 3.1:
>> - "the starting point category is a small COLLECTION ..." to avoid
>> confusion, use SET instead.
>>
>> - definitions entity/activity/etc need updating
>>
>> - "In this case, the Agent that influenced an Activity or Entity
>> prov:actedOnBehalfOf another Agent that MAY HAVE HAD LESS INFLUENCE, but
>> still bears some responsibility for the resulting Activity or Entity." I
>> am not sure we should say this at all. The agent may or may not have had
>> more or less influence.
>>
>>
>> - MailScanner has detected a possible fraud attempt from "example.org"
>> claiming to be http://example.org# -> http://example.org/# ? everywhere
>>
>> - example after fig 1: it would be nice to see a "prov-style" picture
>>
>> - example 2 (agent derek) ... it was suggested for prov-dm that
>> examples should be described in past tense. It should be done here
>> too.
>>
>> - i don't understand wy ex:post9821v1 is a specialization of ex:post9821,
>> I can see it's an alternate. (in example code and in text)
>>
>> - inmediately->immediately
>>
>> - "Since the provenance produced by the activities of Derek and Monica
>> correspond to different user views, the system automatically publish it in
>> different prov:Bundles (ex:bundlePost and ex:bundlePost1)." I don't
>> understand. It is part of the scenario? or is part of prov?
>>
>>
>> - I am lost in the example without a picture
>>
>> - Suggestion: number examples
>>
>> - an example still has prov:hasAnnotation
>>
>> - "and all the data related to the post is lost. " permanently?
>>
>> - example: bundles have not been used, so what is their point?
>>
>> - figure 3: can we keep the conventions used elsewhere: agent is represented
>> by pentagon.
>>
>> - comments in some of the example (e.g. qualified usage) go beyond the box,
>> into the margin
>>
>> - cross referencing, I am not against it, I am concern about the additional
>> space it takes.
>> Can it be folded in the title section?
>> It's probably too early at this stage to link to constraints, though
>> this would be valuable once the prov-constraints document is stable.
>>
>> - examples: dererk -> dereck
>>
>> - examples: to save space, can we define all prefixes upfront and avoid
>> repeating them
>>
>> - prov:wasDerivedFrom contains definition of entity, and not of derivation
>>
>> - prov:Bundle: the text talks about account
>>
>> - prov:Bundle: maybe should state the purpose: provenance of provenance
>>
>> - prov:alternateOf: contains definition of software agent
>>
>> -<> prov:wasDerivedFrom< .... dm ...> :
>> I guess it's always good to eat our own dog food, but I think this
>> complicates
>> the examples.
>>
>> - prov:invalidatedAtTime the painter seem to be destroyed in 2012???
>>
>> - prov:mentionOf/specializationOf: have software agent as definition.
>>
>> - prov:value: "The main value ... of a STRUCTURED value."
>> What is structured, here?
>>
>> - prov:wasInvalidatedBy example:
>> Is it right to say swissair_flight_111_crash prov:used<http//db....
>> swissair_flight_111>?
>>
>> - prov:Influence and its subclasses: can they be used alone without a
>> concrete influence?
>> Shouldn't the text say something and RECOMMEND the use of subclasses?
>>
>> - prov:Communication is not allowed in the domain of atLocation (see
>> example for prov:Communication)
>>
>> - typo: prov:Actvity in example with policySale
>>
>> - Delegation is not in the domain of hadRole (see insuranceAgent_Frank)
>>
>> - example of derivation goes into margin
>>
>> - EntityInvolvment: comments that appear in the example should be given in
>> the narrative.
>>
>> - Quotation no longer has hadQuoter and hadQuoted in prov-dm
>>
>> - prov:Revision, the binary wasAttributedTo is incorrectly qualified by an
>> Association
>> instead of Attribution
>>
>> - example for prov:hadGeneration
>> has a qulaifiedDerivation,
>> dont' you need to specifiy influencer entity?
>>
>> - no role allowed in attribution
>>
>> :nationalRegionsList
>> a prov:Entity;
>> prov:qualifedAttribution [
>> a prov:Attribution;
>> prov:agent :civil_action_group;
>> prov:hadRole :owner;
>> ]
>> .
>>
>>
>>
>> - no role in delegation
>>
>> :chauffeur
>> a prov:Person;
>> prov:actedOnBehalfOf :celebrity-in-car;
>> prov:qualifiedDelegation [
>> a prov:Delegation;
>> prov:agent :celebrity-in-car;
>> prov:hadRole :employer; # The celebrity employed the chauffeur during
>> the enforcement.
>> ];
>> .
>>
>> - prov:qualifiedDerivation
>> :bar_chart
>> prov:wasDerivedFrom :aggregatedByRegions;
>> prov:qualifiedDerivation [
>> a prov:Derivation;
>> prov:hadGeneration :illustration;
>> ];
>> .
>>
>> Shouldn't you link to :aggregatedByRegions;?
>>
>> - qualifiedInvalidation: check time of crash
>>
>> - prov:qualifiedQuotation uses quoter/quotedAgent
>>
>>
>> - qualified source
>> :temperatureDisplay
>> a prov:Entity;
>> prov:hadOriginalSource :sensorReading20120510;
>> prov:qualifiedSource [
>> a prov:Source;
>> prov:entity :sensorReading20120510;
>> ];
>> .
>>
>> Isn't there a RECOMMENDation to use the qualified pattern only if it adds
>> new information?
>> It does not do it here.
>>
>>
>> - qualified usage
>>
>> :newsPublication
>> a prov:Activity;
>> prov:used :tsunami_image;
>> prov:qualifiedUsage [
>> a prov:Usage;
>> :hasCopyrightPermission :licensedUse;
>> :hasOwner :reuters;
>> ];
>>
>> Need to add prov:influencer tsunami_image
>>
>>
>> -
>>
>> prov:ProvenanceService
>> prov:hasAnchor prov:hasProvenance prov:hasProvenanceService
>> prov:provenanceUriTemplate
>> Should not be described in the html document, but in the paq document.
>>
>>
>> - appendix
>> # Instead of defining their own, modelers should use the
>> # recommended inverse local name within the PROV namespace:
>>
>> This is confusing. So, it would be better to say that they are defined in
>> prov namespace
>> though not defined in prov-o.html ( a bit like paq stuff). It would be
>> informative.
>>
>> - OWL2 primer should be normative reference
>>
>>
>>
>>
>> On 04/07/2012 10:26, Luc Moreau wrote:
>>
>>
>>
>> Hi prov-o team,
>>
>> Thanks for producing the document. Here are a few comments on the ontology,
>> before I start reading
>> the html document.
>>
>> I think you removed too many of the property characteristics, some of which
>> are prov-o specific
>> (as opposed to being prov-constraints specific).
>>
>> Otherwise, I think the ontology is aligned with prov-dm. I think that
>> Influence and influencer are
>> quite nice!
>>
>> Cheers,
>> Luc
>>
>>
>> 1. hadRole: why is domain defined as intersection of Influence and six of
>> its subclasses.
>> Why not the subclasses directly?
>>
>>
>> 2. qualifiedXXX: shouldn't they be inverseFunctional?
>> Otherwise, this would allow for a given Influence instance, to be a
>> qualified Influence
>> for multiple subjects. This is not intended.
>>
>> The qualified pattern is prov-o specific. It was inverse functional before,
>> but I think
>> this characteristic was incorrectly removed.
>>
>> 3 influencer: should it be functional: there is only one influencer per
>> qualified pattern instance, isn't there.
>>
>> 4. Likewise:
>> hadPlan: is functional
>> hadUsage: is functional
>> hadGeneration: is functional
>> hadActivity: is functional
>>
>> As per prov-dm.
>>
>> 5. generatedAtTime: In owl file: editorialNote "It is the intent that the
>> property chain holds: (prov:qualifiedGeneration o prov:atTime)
>> rdfs:subPropertyOf prov:generatedAtTime."@en
>>
>> --> It cannot be functional since qualifiedGeneration is not functional.
>>
>> Also applies to all the others, invalidatedAtTime, startedAtTime,
>> endedAtTime,
>>
>>
>> Cheers,
>> Luc
>>
>>
>> On 03/07/2012 21:20, Provenance Working Group Issue Tracker wrote:
>>
>>
>>
>> PROV-ISSUE-444 (prov-o-to-last-call): Review PROV-O for last call [PROV-O
>> HTML]
>>
>> http://www.w3.org/2011/prov/track/issues/444
>>
>> Raised by: Timothy Lebo
>> On product: PROV-O HTML
>>
>> PROV-O is ready for internal review for Last Call release.
>>
>> The document is at:
>>
>> http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/last-call/2012-07-03-internal-review/Overview.html
>>
>> Please respond to this thread with general feedback and answers to the
>> following questions:
>>
>> 1) Are there any issues that should delay the WG's release of PROV-O as Last
>> Call (i.e., is all of the technical work done).
>>
>>
>> 2) Are the examples and scenario adequate?
>>
>>
>> 3) Should the links to prov-dm, prov-constraints, and prov-n stay in the
>> cross reference?
>>
>> Regards,
>> Tim prov:actedOnBehalfOf :prov-o-team .
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Received on Thursday, 12 July 2012 09:27:29 UTC