Question: CRM transitive properties

[Vladimir Alexiev]

> From: Vladimir Alexiev [mailto:vladimir...@ontotext.com]
> Sent: Tuesday, March 20, 2012 10:40 AM

> Can the community confirm that properties such as
> P106_is_composed_of, P148_has_component, P115_finishes, etc
> should in fact be transitive, as declared in http://erlangen-crm.org/onto/ecrm_current.owl?

For a practitioner it's very important to know whether the "part of" and similar properties are transitive or not.
Could the community please comment?

> From the scope notes it makes all sense they should be transitive, but the notes don't mention it explicitly...

There is an argument to have non-transitive variants ("step relations") as well: step relations are useful to find the immediate parts.
(One could obtain the same in a non-standard way, e.g. ask an OWLIM repository to return only explicit (not inferred) facts).
Maybe we need several versions, e.g.
- P9_consists_of: forward step relation
- P9i_forms_part_of: inverse step relation
- P9T_consists_of: forward transitive relation
- P9Ti_forms_part_of: inverse transitive relation

> shouldn't P9_consists_of and P46_is_composed_of (and their inverses) also be transitive?
> Isn't this an inconsistency in ECRM?

Also: ecrm:P133_is_separated_from is a SymmetricProperty but is not declared as its own inverse
(unlike all other symmetric properties)

A summary of the symmetric and transitive properties:

owl:TransitiveProperty
P9_consists_of P9i_forms_part_of (MUST ADD)
P10_falls_within P10i_contains
P46_is_composed_of P46i_forms_part_of (MUST ADD)
P86_falls_within P86i_contains
P88_consists_of P88i_forms_part_of
P89_falls_within P89i_contains
P106_is_composed_of P106i_forms_part_of
P114_is_equal_in_time_to
P115_finishes P115i_is_finished_by
P116_starts P116i_is_started_by
P117_occurs_during P117i_includes
P120_occurs_before P120i_occurs_after
P127_has_broader_term P127i_has_narrower_term
P148_has_component P148i_is_component_of
owl:SymmetricProperty
P69_is_associated_with
P114_is_equal_in_time_to
P121_overlaps_with
P122_borders_with
P132_overlaps_with
P133_is_separated_from (NOT DECLARED self-inverse)

[Mark Fichtner]

Dear Vladimir,

On Wednesday, January 22, 2014 1:34:40 PM UTC+1, Vladimir Alexiev wrote:

> From: Vladimir Alexiev [mailto:vladimir...@ontotext.com]
> Sent: Tuesday, March 20, 2012 10:40 AM

> Can the community confirm that properties such as
> P106_is_composed_of, P148_has_component, P115_finishes, etc
> should in fact be transitive, as declared in http://erlangen-crm.org/onto/ecrm_current.owl?

For a practitioner it's very important to know whether the "part of" and similar properties are transitive or not.
Could the community please comment?

I think that they should. In the process of the creation of the ECRM we also thought about this problem a lot and tried to decide based on the scope note if the property should be transitive, or not.

 

> From the scope notes it makes all sense they should be transitive, but the notes don't mention it explicitly...

There is an argument to have non-transitive variants ("step relations") as well: step relations are useful to find the immediate parts.
(One could obtain the same in a non-standard way, e.g. ask an OWLIM repository to return only explicit (not inferred) facts).
Maybe we need several versions, e.g.
- P9_consists_of: forward step relation
- P9i_forms_part_of: inverse step relation
- P9T_consists_of: forward transitive relation
- P9Ti_forms_part_of: inverse transitive relation

We also think that it would be good if the transitivity would be stated explicitely in the scope note. Furthermore there are several scope notes which make a logical handling rather difficult e.g. P130 - the scope note states " This property generalises the notions of "copy of" and "similar to" into a dynamic, asymmetric relationship, where the domain expresses the derivative, if such a direction can be established. Otherwise, the relationship is symmetric." - Perhaps this should be splitted? The same holds für P139.

> shouldn't P9_consists_of and P46_is_composed_of (and their inverses) also be transitive?
> Isn't this an inconsistency in ECRM?

We discussed several times if P46_is_composed_of is a transitive property. As it is not stated explicitely we did not make it transitive by now. Furthermore the scope note reads like it is rather closeley related to P134_continued. The same holds for P5 consists of and P9 consists of. It would be best if it would be explicitely stated by the SIG if they are transitive or not.

  

Also: ecrm:P133_is_separated_from is a SymmetricProperty but is not declared as its own inverse
(unlike all other symmetric properties)

That is probably a bug, I already fixed it on our website and on github - thank you!

 

A summary of the symmetric and transitive properties:

owl:TransitiveProperty
  P9_consists_of P9i_forms_part_of (MUST ADD)
  P10_falls_within P10i_contains
  P46_is_composed_of P46i_forms_part_of (MUST ADD)
  P86_falls_within P86i_contains
  P88_consists_of P88i_forms_part_of
  P89_falls_within P89i_contains
  P106_is_composed_of P106i_forms_part_of
  P114_is_equal_in_time_to
  P115_finishes P115i_is_finished_by
  P116_starts P116i_is_started_by
  P117_occurs_during P117i_includes
  P120_occurs_before P120i_occurs_after
  P127_has_broader_term P127i_has_narrower_term
  P148_has_component P148i_is_component_of 

owl:SymmetricProperty
  P69_is_associated_with
  P114_is_equal_in_time_to
  P121_overlaps_with
  P122_borders_with
  P132_overlaps_with
  P133_is_separated_from (NOT DECLARED self-inverse)

P69 is not a symmetric property in the current draft anymore. However currently we are unsure how to handle the drafts.

Best Regards,

Mark 

[Martin Scholz]

Hi,

2014-01-22 Vladimir Alexiev <vlad...@sirma.bg>:

There is an argument to have non-transitive variants ("step relations") as well: step relations are useful to find the immediate parts.
(One could obtain the same in a non-standard way, e.g. ask an OWLIM repository to return only explicit (not inferred) facts).
Maybe we need several versions, e.g.
- P9_consists_of: forward step relation
- P9i_forms_part_of: inverse step relation
- P9T_consists_of: forward transitive relation
- P9Ti_forms_part_of: inverse transitive relation

I think the "non-standard way" is a better solution for querying explicit triples as it does not only occur with transitivity but all inferred triples, even property and class hierachy: There is also no special rdf:type variants for explicit vs. inferred triples.

However, I think such variants could solve two problems in the ECRM:

1) There are some supposedly transitive properties like P5 and P9 that also contain cardinality constraints. In OWL DL however, we cannot combine both. [1] says for the OWL DL profile that "in number restrictions, only simple roles (i.e. which are neither transitive nor have a transitive subroles) are allowed; otherwise we gain undecidability even in SHN;"

It is obvious that inferencing with transitivity and card restrictions may give some unwanted results: in the case of P5 and P9 we have maxCard 1 which makes no sense for a transitive property! The card restrictions in ECRM and CRM are rather meant to apply to the explicitly statet facts not the transitive closure.

In the ECRM, we decided to favour card constraints over transitivity. One argument is that quantification is always expressed explicitly in the CRM, while transitivity is not. I know, that some poeple would rather like to have transitivity. So, to have both in ECRM, one could borrow the modelling of transitive "broader term" in SKOS [2] that relies on transitivity not being inherited: there could be e.g. a transitive property P9T without card restrictions and a non-transitiv subproperty P9 with card restrictions.

So, if one needs restrictions one can use the P9 level and for transitivity one can switch to the P9T level.
People who don't care about card restrictions could ignore P9 without affecting the hierarchy.

2) The CRM leaves the symmetric nature of some properties open, depending on subtyping ("dynamic asymmetric", etc.). Version 5.1.2 states for property P69: "The property is considered to be symmetrical unless otherwise indicated by P69.1 has type." Same holds at least for P130 and P139.

As the ECRM does not handle dot-1-property subtyping, two variants could be introduced: a symmetric one and a non-symmetric one.

Comments?

Martin Scholz

[1] http://www.cs.man.ac.uk/~ezolin/dl/
[2] http://www.w3.org/TR/skos-primer/#sectransitivebroader

[Vladimir Alexiev]

1. I don't know of anyone using OWL restrictions, do you? A couple years back there was even a workshop "OWL 2 much" :-)

2. > There is also no special rdf:type variants for explicit vs. inferred triples.

Yes, that is a bit of a problem because of the deep CRM class hierarchy. In my experience witih BM, 35-40% of all statements are type statements.

How did PolishDL deal with this: they just killed the rdfs:subClassOf rules. So they can only query by explicit type; but can add an extra query clause if they want to query for sub-types.

3. I recently learned with surprise that CRM says: "Properties that have identical domain and range are either symmetric or transitive" (v5.1.2 page 23). 

I can guess the philosophical underpinnings of such princiople. But it is quite a strong statement, is it universally valid?

(LATER) The scope notes of P130 and P139 show it is not universally valid.

4. P69 "considered to be symmetrical unless otherwise indicated by P69.1 has type." 

P130 [and P139]: "asymmetric relationship, where the range [domain] expresses the derivative, if such a direction can be established. Otherwise, the relationship is symmetric.

P139: "The relationship is not transitive"

>  two variants could be introduced: a symmetric one and a non-symmetric one.

Too much trouble/complexity. I think they should not be declard as Symmetric. 

If a particular instance is symmetric, the creator can create it in both directions.

Or if a specific subproperty is symmetric, it can be declared as Symmetric, eg:

  PX130_1_similar_to rdfs:subPropertyOf P130_shows_features_of; a owl:SymmetricProperty.

  PX130_2_copy_of    rdfs:subPropertyOf P130_shows_features_of. # could even declare AsymmetricProperty