W3C home > Mailing lists > Public > public-prov-wg@w3.org > February 2012

Re: PROV-ISSUE-268 (two-level-ontology): Two Level Ontology? [Ontology]

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Mon, 27 Feb 2012 14:47:57 +0000
Message-ID: <CAPRnXt=FCZhOQXF3-OQCswf39=V0pYr9jrayDLRRGciv8B_v-A@mail.gmail.com>
To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Cc: public-prov-wg@w3.org
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 vocabulary.

However binary relationships like prov:used are in provA also
'exploded' into prov:Usage, prov:usedEntity and prov:usingActivity.

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:

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 ;

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.

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

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Monday, 27 February 2012 14:48:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:08 UTC