Re: Are qualified<Foo> relations IFPs?

Is round-tripping PROV-O and PROV-N a requirement?  That could well be a can of 
worms.

Something I haven't seen in the specs I've is a description of the mapping 
between PROV-N and PROV-O (that's one of my comments on PROV-O).

#g
--

On 10/07/2012 11:52, Stian Soiland-Reyes wrote:
> PROV-O uses the qualifiedXX to map to these PROV-DM relations.
>
> However, there is as far as I can tell - not a requirement in PROV-DM
> that this is not allowed:
>
> activity(act1)
> activity(act2)
> entity(ent1)
> usage(use1; act1, ent1)
> usage(use1; act2, ent1) // Same identifier for the usage!
>
> Thus, to represent this (very) scruffy provenance, qualifiedUsage will
> have to *not* be inverse functional:
>
> :ent1 a prov:Entity .
>
> :act1 a prov:Activity ;
>      prov:used :ent1;
>      prov:qualifiedUsage :use1 .
>
> :act2 a prov:Activity ;
>      prov:used :ent1;
>      prov:qualifiedUsage :use1 .
>
> :use1 a prov:Usage ;
>      prov:entity :ent1 .
>
>
> This is of course 'very scruffy' provenance. We could argue strongly
> that PROV-DM should NOT allow this, in which case the prov:qualified*
> should be made inverse functional.
>
>
>> From the same argument prov:entity and friends should not be
> functional, to allow:
>
> usage(use1; act1, ent1)
> usage(use1; act2, ent2) // Same identifier for the usage!
>
> :use1 a prov:Usage ;
>      prov:entity :ent1, :ent2 .
>
>
> .. but this is where it breaks down, as now you can't go back to the
> separate usage() statements.
>
>
> I think the conclusion of this is that it opens a can of worms, and
> both PROV-DM and PROV-O should restrict the identifiers of
> relations/influences and define if that is allowed and/or what it
> means.  Thus PROV-O can reflect this, and provide better guidance.
>
>
> Alternatively, we can say that if you are scruffy, then you only use
> the vocabulary of PROV-O, and might be in conflict with OWL
> restrictions, which can then reflect more of the PROV-Constraints.  I
> am not so sure about this approach.
>
>
>
> On Tue, Jul 10, 2012 at 9:40 AM, Graham Klyne<graham.klyne@zoo.ox.ac.uk>  wrote:
>> Hi,
>>
>> I don't think the qualified<Foo>  relations need to be inverse functional,
>> and in some cases it may be important that they are not.
>>
>> I don't think it matters if there are (say) multiple qualifiedUsage classes
>> between (say) a given entity and an activity, as long as they refer to the
>> same values.
>>
>> When we start to look at provenance of provenance, I think it's important
>> that they be separate, so that provenance of qualifiedUsage assertions that
>> provide different information facets about the usage can be assessed
>> accordingly.
>>
>> There will be constraints on what are considered valid (satisfiable) overall
>> provenance assertions that flow from the formal semantics of PROV, so that
>> conflicting claims can be treated as such.
>>
>> Sorry this is all vague and hand-wavy, but I wanted to weigh in against
>> imposing ontological constraints/commitments that may turn out to be
>> unnecessary or even harmful.  For specs based around an open-world model,
>> it's easier to add constraints later than to retract them.
>>
>> #g
>> --
>>
>>
>> On 09/07/2012 20:08, Luc Moreau wrote:
>>>
>>> Hi Tim,
>>>
>>> We cannot really afford to wait till Thursday to make progress on this.
>>> We need to try and resolve it by email.
>>>
>>> For #2.
>>> The reason for qualifiedXXX is inverse functional is that
>>> when we write an expression such as
>>> usage(id;a,e,t,[attr1=v1,attr2=v2])
>>> there is a single activity and a single entity per usage.
>>> So, qualifiedUsage is inverse functional and influencer is functional.
>>> Likewise hadActivity/hadPlan/hadXXX are functional.
>>>
>>> I pointed out that this was PROV-O specific, because the qualified pattern
>>> is introduced by prov-o, not prov-dm.
>>>
>>>
>>> For #5, I was just following your editorial note "It is the intent that
>>> the property chain holds: (prov:qualifiedGeneration o prov:atTime)
>>> rdfs:subPropertyOf prov:generatedAtTime."
>>>
>>> If qualifiedGeneration is not functional, I suppose that generatedAtTime
>>> cannot be functional.
>>> But maybe, I am wrong.
>>>
>>> Luc
>>>
>>> ________________________________________
>>> From: Timothy Lebo [lebot@rpi.edu]
>>> Sent: Monday, July 09, 2012 6:06 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,
>>>
>>> The prov-o team discussed this during our telcon today.
>>>
>>> Are the property characteristics that you suggest justified by DM?
>>>
>>> You do point out that some are "PROV-O specific", but they should still
>>> have grounding in DM, right?
>>>
>>> The team thinks that these characteristics should be discussed at the WG
>>> level.
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>>
>>> On Jul 4, 2012, at 5:26 AM, Luc Moreau wrote:
>>>
>>> …
>>>
>>>>
>>>> 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 .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

Received on Tuesday, 10 July 2012 15:16:07 UTC