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

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

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.

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

Received on Tuesday, 25 October 2011 09:07:30 UTC