- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Thu, 12 Jul 2012 10:44:18 +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>
All,
Question: do we keep EmptyCollection?
Luc
On 07/12/2012 10:38 AM, Stian Soiland-Reyes wrote:
> It's not generally a derivation in my view, unless by 'my:Membership'
> you mean 'JoiningTheCollection' - I would have done it as an
> wasInfluencedBy.
>
> But OK. I welcome our new simplicity overlords. It is clean enough to
> obviously leave open questions such as completeness.
>
> On Thu, Jul 12, 2012 at 10:26 AM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
>> 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:44:53 UTC