- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Thu, 12 Jul 2012 10:10:28 +0100
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: "public-prov-wg@w3.org" <public-prov-wg@w3.org>, Timothy Lebo <lebot@rpi.edu>
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
>
>
>
>
>
>
>
>
>
>
>
--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Thursday, 12 July 2012 09:11:20 UTC