P106_has_component / P106_is_composed_of

pierrechoffe commented 8 years ago

Hello,

We are working on a new ontology for music called DOREMUS and extending CIDOC CRM and FRBRoo. We import ecrm: http://erlangen-crm.org/current/ and efrbroo: http://erlangen-crm.org/efrbroo/

We noticed there are two P106 properties imported:

P106_has_component
P106_is_composed_of

Both are superproperties of different FRBRoo properties.

To be complete, I should also mention that (1) the official name of P106 in CRM is "is composed of" (2) P106_has_component only has one FRBRoo subproperty : R14_incorporates, which is deprecated.

Can you be so kind as to check where the problem lies? With all best wishes, Pierre Choffé

pierrechoffe commented 8 years ago

Please note that ecrm: http://erlangen-crm.org/current/ does not mention P106_has_component. efrbroo: http://erlangen-crm.org/efrbroo/current/ does mention the wrong property P106_has_component at:

line 1117
line 1822

and P106_is_composed_of everywhere else.

rtroncy commented 8 years ago

efrbroo: http://erlangen-crm.org/efrbroo/current/ does mention the wrong property P106_has_component

It is more than just mentioning ... it is bringing a definition. This is also not considered as a good practice to hijack a namespace by (re-)defining terms in another ontology. Hence, is it an oversight that the efrbroo ontology defines terms in the ecrm ontology?

ghohmann commented 8 years ago

@pierrechoffe The CIDOC CRM labels the property as "P106 is composed of (forms part of)". Therefore the ECRM 'current' states "P106 is composed of" and as inverse "P106 forms part of".

The OWL representation of the EFRBROO is a very old one, and there isn't much time left to keep it up to date as the ECRM. Nevertheless, the mentioning of "P106_has_component" is simply wrong and should be changed. Maybe the community can help? ;-)

@rtroncy

It is more than just mentioning ... it is bringing a definition. This is also not considered as a good practice to hijack a namespace by (re-)defining terms in another ontology. Hence, is it an oversight that the efrbroo ontology defines terms in the ecrm ontology?

What do you mean by "it is bringing a definition"? As I see it, the FRBROO does not define "P106" (no scope note etc.), it just refers to it. So in my opinion there is no hijacking attempt. Could you elaborate on this?

rtroncy commented 8 years ago

Therefore the ECRM 'current' states "P106 is composed of" and as inverse "P106 forms part of".

Don't you want to number P106i the inverse?

The OWL representation of the EFRBROO is a very old one

Are you aware of a newer OWL version of the FRBRoo ontology? Are you recommending to not re-use this ontology?

What do you mean by "it is bringing a definition"? As I see it, the FRBROO does not define "P106" (no scope note etc.), it just refers to it. So in my opinion there is no hijacking attempt. Could you elaborate on this?

It does. See the line 1117 of this file. This line does define a property in the ercm namespace. Note that this line is completely unnecessary since you import already the ecrm ontology.

mnscholz commented 8 years ago

Hi,

I think the definition statement is due to Protege's serialization method (with which the ontology file was created). My 5.x branch re-declares/defines every imported property or class.

Also, a new efrbroo version that adopts the latest frbroo draft is currently in the making. (And P106 has been fixed there...)

Martin

2016-09-15 22:46 GMT+02:00 Raphael Troncy notifications@github.com:

Therefore the ECRM 'current' states "P106 is composed of" and as inverse "P106 forms part of".

Don't you want to number P106i the inverse?

The OWL representation of the EFRBROO is a very old one

Are you aware of a newer OWL version of the FRBRoo ontology? Are you recommending to not re-use this ontology https://github.com/erlangen-crm/efrbroo/blob/releases/efrbroo.owl

What do you mean by "it is bringing a definition"? As I see it, the FRBROO does not define "P106" (no scope note etc.), it just refers to it. So in my opinion there is no hijacking attempt. Could you elaborate on this?

It does. See the line 1117 of this file https://github.com/erlangen-crm/efrbroo/blob/releases/efrbroo.owl. This line does define a property in the ercm namespace. Note that this line is completely unnecessary since you import already the ecrm ontology.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/erlangen-crm/ecrm/issues/1#issuecomment-247450532, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUJSExdHTVAVWh4ecP4RdpeRnAc1RJ1ks5qqa6egaJpZM4J83Mm .

rtroncy commented 8 years ago

Also, a new efrbroo version that adopts the latest frbroo draft is currently in the making. (And P106 has been fixed there...)

@mnscholz This is good to know. Where can we track this new version? Is it edited in this repository? If not, why? When is a new version supposed to be delivered? This is really important and urgent for us, the DOREMUS ontology that depends on it.

mnscholz commented 8 years ago

I uploaded the current state of the efrbroo (efrbroo_20160715.owl). It reflects all the changes up to frbroo 2.4.

If you find an error, feel free to open an issue or/and to provide a patch. :)

Please note that this version is not owl dl as it (experimentally) implements property chains ("shortcuts") which conflict with other statements. If you need a version that can be loaded in a reasoner like hermit etc. just delete the property chain statements.

rtroncy commented 8 years ago

Thanks, we will review this new version. We love property chains :-)

VladimirAlexiev commented 8 years ago

Please note that the CRM SIG doesn't like Restrictions, and if I remember correctly also prop chains. I personally think it's a worthy effort.
while efrbroo declares prop chains, ecrm does not, which means if you do prop chain reasoning, it will be incomplete
posted bugs/tasks related to prop chains: https://github.com/erlangen-crm/efrbroo/issues/3, https://github.com/erlangen-crm/efrbroo/issues/4, https://github.com/erlangen-crm/efrbroo/issues/6

rtroncy commented 6 years ago

We are happy to close this issue now.

VladimirAlexiev commented 6 years ago

But I'm not ;-) I checked a few, and the first couple I stumbled upon seem wrong:

efrbroo:R57_is_based_on owl:propertyChainAxiom (ecrm:P94i_was_created_by ecrm:P17_was_motivated_by) R57 gives this example: ‘Alexander’ (F38_Character in a play by Mary Renault) R57_is_based_on Alexander the Great (E39_Actor historic person). Yes, you can say that the creation of the character was motivated by the historic person. But you CANNOT say that ANY creation of a conceptual object motivated by SOMETHING results in R57.
- Mary Renault's work on the character may have been motivated by a nice drink of cognac; this doesn't mean that the character R57_is_based_on cognac.
- If you do not also check types, that would infer wrong types for the first and last node in the chain
efrbroo:R20i_was_recorded_through owl:propertyChainAxiom (ecrm:P9i_forms_part_of ecrm:P9_consists_of ecrm:P15i_influenced)
- again this doesn't check types (which must be ecrm:E2_Temporal_Entity and efrbroo:F29_Recording_Event)
- And it has an even more sinister effect: ANY Period that has a part also has a chain P9i-P9 looping back to itself. This means for every such period, P15i_influenced effectively becomes a subproperty of R20i_was_recorded_through, which is obviously false.

The meaning is that SOME of these chains imply the given property. But owl:propertyChainAxiom means that ALL such chains infer the given property, which is not the same thing.

You cannot express combinations of property chains and type checks in OWL2. For stuff like this, see http://vladimiralexiev.github.io/pres/extending-owl2/ and search for PropChainType2, PropChainRestrType2Restr

erlangen-crm / ecrm

P106_has_component / P106_is_composed_of #1