Re: PROV-ISSUE-383 (how-to-handle-subtypes): How to handle subtypes in PROV-DM [prov-dm]

FWIW, CIDOC CRM exhibits a similar diversity of patterns.  It uses direct 
subtyping for key built-in concepts, and then a kind of type annotation for less 
central typing.  I'm not saying it's a good or a bad thing, just saying.

It would be interesting to see how this diversity of subtyping plays out in 
PROV-O - which as I understand could use direct subtypes and subproperties, or 
can use qualified relations.

Within PROV-N, I think the "easy" way to deal with subtypes/subproerties 
consistently would be to use type annotations for everything, but I'm not sure 
if that would introduce undesired complexities in practical use.

Also, I think it might be reasonable to treat concepts and relations separately. 
  I suspect that, at least for usage with RDF, subtyping is such a common idiom 
that it won't go away - I think creating subtypes of Entity, Activity and Agent 
would seem very natural to most semweb developers.  With properties, it's not so 
clear.  I think it may be harder to optimize triple store lookups when you are 
not working with fixed property names (which arbitrary use of sub-properties 
would tend to introduce).  One of the harsher lessons of mapping RDF onto XML is 
that not having a pre-ordained set of XML tags makes it harder to use XML tools 
effectively.  I speculate that not having a pre-ordained set of RDF properties 
for handling provenance data may lead to some comparable problems.

My tentative intuition, then, is this:

(1) use direct subtyping for subsets of Entity, Activity and Agent.

(2) use type annotations for suptypes of the various relations.

#g
--


On 23/05/2012 13:49, Provenance Working Group Issue Tracker wrote:
> PROV-ISSUE-383 (how-to-handle-subtypes): How to handle subtypes in PROV-DM [prov-dm]
>
> http://www.w3.org/2011/prov/track/issues/383
>
> Raised by: Luc Moreau
> On product: prov-dm
>
>
> PROV-DM defines a variety of subtypes and handles them differently.
>
> Some have an explicit prov-n construct (I think for those, it's a legacy
> of the past, when signatures were not uniform).
>
> Some are explicitly represented in UML diagrams, some are not.
> Some are listed in table 4.
>
>                            PROV-N      in UML  in Table 4
>                           notation       diag
>
> wasRevisionOf              yes          yes      yes
>
> hadOriginalSource          yes          yes      yes
>
> wasQuotedFrom              yes          yes      yes
>
> prov:Plan                  no           yes       no
>
> prov:SoftwareAgent         no           no        no
>
> prov:Organization          no           no        no
>
> prov:Person                no           no        no
>
> prov:Bundle                no           yes       yes
>
> prov:Collection            no           yes       yes
>
> prov:Dictionary            no           yes       yes
>
> prov:EmptyDictionary       no           no        no
>
> Suggestions on how to handle them systematically are welcome!
>
> Luc
>
>
>
>

Received on Tuesday, 29 May 2012 09:57:45 UTC