- From: Myers, Jim <MYERSJ4@rpi.edu>
- Date: Mon, 28 Nov 2011 14:21:17 +0000
- To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>, Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- CC: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
> > I did not argue that necessarilyDerivedFrom should have any formal > semantics, I think there is a way to formalize this, but it may be a bit beyond the standard (so this may be an aside): B necessarilyDerivedFrom A is an assertion that the process connections between B and A and any entities in intermediate steps between B and A cannot be decomposed in ways that would disconnect B from A. I.e. the asserter doesn't believe there is any more detailed description of the provenance where, for example, [B was created by a sub-process that did not use A], or where [B is really part of some intermediate that was derived from A but if you decompose the intermediate you find that the B part was not derived from A]. If we don't have a clear sense of process and entity decomposition, we can't use this definition formally, but I think it captures the right idea of what "truly" derived from means... (note: the asserter may not know what process(es) connect B and A and may not know how to do the decomposition, so it can remain an assertion. If the standard was ever extended (or if domain ontologies extend it) to allow assertions of processes and entities to be labeled as 'atomic', one could also infer necessarilyDerivedFrom - is it just this part that is outside the standard - i.e. the definition here works but we're limited to making it an assertion only?) Jim
Received on Monday, 28 November 2011 14:22:23 UTC