- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Mon, 27 Feb 2012 17:57:37 +0100
- To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- CC: public-prov-wg@w3.org
Hi Stian, Comments interleaved. On 27/02/2012 15:47, Stian Soiland-Reyes wrote: > On Mon, Feb 27, 2012 at 14:01, Luc Moreau<l.moreau@ecs.soton.ac.uk> wrote: > > > >> What do you mean by 3 ways? It's exactly the same number of ways as in the >> current ontology. >> > I had a second look at your ontology and retract some of my earlier comments. > > I had not noticed that you had made the prova: properties be organized > as subproperties of prov:entity or provb:involved in provb. > > As far as I understand, provA will let you say pretty much what's in > PROV-DM, but does not have any unifying structure between the classes > and properties - the only structure there is that a prova:Agent is > subclass of prova:Entity. Thus it is more of a pure vocabul Yes, it's correct. The data model does not define any other structure really. > ary. > > > However binary relationships like prov:used are in provA also > 'exploded' into prov:Usage, prov:usedEntity and prov:usingActivity. > There used to be an equivalent to prova:usingActivity which was prov:hadQualifiedUsage. I know it was removed, but that's the origin of some of the strange inferences such as entity used entity. > Thus we get 4 classes/properties per relation, and this can be quite > confusing as they seem to be doing almost the same thing. A quick > estimation says that this will be 16 x 3 = 48 properties and 16 > classes to express the 16 subproperties we currently have of > prov:involved. In provO there will be the additional prov:used and > prov:entity/prov:activity as of today, so then you have 3 ways to > express the same thing: > > > You seem to forget that quite a few prob properties can be inferred. > provA binary: > > :entity1 prova:wasGeneratedBy :act1 . > > > provA "involvement": > > :gen1 a prova:Generation ; > prova:generatedEntity :entity1 ; > prova:generatingActivity :activity1 . > > > provB involvement (almost like today): > > :activity1 prov:involved :gen1 . > :gen1 a prova:Generation ; > provb:entity :entity1 ; > > > provA and provb involvement are the same. There is only two ways of expressing a use, either by instance of a Usage or by a prova:used, like in the current ontology. provb:entity and provb:involved can be inferred. > I believe that if we go for a vocabulary, we should not have both > options exposed there - the vocabulary should only have the binary > relationships and truly be 'simple' and straight-forward. > > > With Tim's current approach (which provB nicely retrofits provA > properties and classes into), you have the binary relationship, say > prov:used, and then there's a "twin" class of prov:Usage. Usage is a > prov:Involvement, and all involvements are applied in the same way, > using prov:involved and prov:activity/prov:entity. Thus you learn the > pattern once, and that you can use the prov:involved form when you > want to assert more about the particular relation. > > > For your solution, this pattern is much more hidden (at least until > you explore provB fully), and it looks like a more complex ontology, > at least in my view. > > > I think what's important for me is to have a clear interchange format (as per charter). The suggested separation helped for it: prova is the interchange format. provb can be used for applications for more advanced reasoning. There may be opportunities to move concepts from provb to prova, but this is to be investigated. Luc > Tim's approach was generally well received as a simple to understand > pattern. The pattern is roughly: > > :b a prov:Entity . > :a prov:someInvolved :b . > > --> > :a prov:involved :X . > :X a prov:SomeInvolvement ; > prov:entity :b . > > (and the same for prov:activity. Some involvements have both activity > and entity). > >
Received on Monday, 27 February 2012 16:58:17 UTC