Re: Prov-o call on Monday 12:00noon US ET

Hi Stian,

Comments below.

On 25/10/2011 10:06, Stian Soiland-Reyes wrote:
> On Mon, Oct 24, 2011 at 21:49, Luc Moreau<l.moreau@ecs.soton.ac.uk>  wrote:
>
>    
>> I am not sure how your proposal deals with generation.  The prov-dm document
>> explains
>> that merging two well-formed accounts (where at most one PE generates an
>> entity) may result
>> in a non well-formed.
>>
>> I believe you have defined wasGeneratedBy property as functional, meaning
>> that a non-well
>> formed account would be inconsistent in the ontology.
>>      
> You are right, to cover this case you would also have to use
> EntityInRole for the generation cases - which is another strong
> argument for renaming it to ContextualisedEntity (the role might not
> even exist) and to not include the shortcut prov:wasGeneratedAt. (I
> included this shortcut thanks to the PROV-DM generation-unicity
> constraint!)
>
> You are right that this is almost like Used and Generated n-ary
> classes, but it is a generalisation that works both for use,
> generation and controlling, while still allowing the shortcut of using
> entities directly.  (We can do n-ary classes without this trick, for
> instance prov:used rdfs:range [ rdfs:unionOf ( prov:Entity, prov:Used)
> ] ]  - but decided that we were first going to try to push
> EntityInRole to the limits to see if it can do the job sufficiently. A
> mere subclass might be less of a distraction than 3 new n-ary
> relationship classes, but we will of course have to explain when it
> should be used.)
>    

Have you actually tried to write it in OWL (ie. ContextualisedEntity 
which would be used for both
use and generation)? My experience with OPMO is that when
defining transitive closures (like wasDependentOn),  some unexpected 
inference
were possible.  But maybe, it will work here.

Luc

> If you want to allow merging two accounts by just appending the two
> RDF resources, then we will be forced to introduce many kinds of n-ary
> relationships and can't allow wasGeneratedAt etc. If an account is
> inconsistent, is it a requirement that it is still to be consistent
> with regards to the ontology? This severely limits what kind of
> constraints we can formulate in the ontology at all. (Those could of
> course be modelled in a separate prov-o-strict.owl ontology)
>
> Such flat merging would also affect issues in PROV-DM - for instance
> the current Collection approach would not work in a merged account.
>
>
> I propose we keep the EntityInRole at this stage, and revisit this
> issue after the FPWD is out - this would give us good chance to
> exercise the model and see if we can break it.
>
>

Received on Tuesday, 25 October 2011 09:22:31 UTC