RE: Are qualified<Foo> relations IFPs? (was: PROV-ISSUE-444 (prov-o-to-last-call))

Hi all,

I accept  the argument of scruffiness here.

I now agree that the properties qualifiedXXX should not be inverse functional.

It would be helpful for me, and maybe others, to see how a scruffy prov-o example
translates to prov-dm. Not in the document, by email or the wiki, would be great.

Thanks,
Luc


________________________________________
From: stian@mygrid.org.uk [stian@mygrid.org.uk] on behalf of Stian Soiland-Reyes [soiland-reyes@cs.manchester.ac.uk]
Sent: Tuesday, July 10, 2012 11:52 AM
To: Graham Klyne
Cc: Luc Moreau; Timothy Lebo; public-prov-wg@w3.org
Subject: Re: Are qualified<Foo> relations IFPs? (was: PROV-ISSUE-444 (prov-o-to-last-call))

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



--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Tuesday, 10 July 2012 16:18:38 UTC