Dear Martin,
Thanks! I was not aware of this :-)
My point is that the Cidoc Definition has become much more usable to me
after adding the inverse properties to each entity entry (and reordering
the entity entries hierachically rather than by number). However, even
though this additional information is readily available in the Cross
Reference, I don't see this semi-minimal approach being easily replaced
by the maximum approach of the Cross Reference.
For understanding a specific entity and when it should be used, it is
useful to know the properties that have this entity as domain and/or
range, i.e. which properties are "new" with this entity. The additional
inverse properties are in a way similar to the "superclass of" and
"superproperty of" information in the Cidoc Definition: Technically this
information is superfluous in a minimal document since it can be deduced
from all "subclass of" and "subproperty of" bits of information, but it
would be tedious to actually find this information for a given entity or
property, or to make sure that no such information exists. On the other
hand, for a given entity, a list of all properties whose domains and/or
ranges equal the entity or any class it inherits from seems overwhelming
if one doesn't already have a good grasp of Cidoc.
But then, maybe it's just me.
Best,
Wolfgang
Am 18.11.12 18:52, schrieb martin:
Dear Wolfgang,
Have you seen this:
http://www.cidoc-crm.org/docs/cidoc_crm_5_0_1_cross_reference/cidoc_crm_5_0_1_cross_reference.rar
?
It is a lot of work, therefore the "crossreference manual" is not
updated by us immediately.
However, there is a CRM-SIG decision long ago to keep the definition
minimal because otherwise
people even more tend to regard the CRM as "too big".
Just let us know, if the crossreference manual is what you meant.
Cheers,
Martin
On 18/11/2012 3:37 μμ, Wolfgang Schmidle wrote:
Dear all,
I would like to make a suggestion: each entity entry should include the
inverse properties that start from this entity. Of course this
information is somehow redundant, but I found that it makes the document
much easier to work with as it is easier to understand how the entities
are used.
Example E35 Title: add the inverse property
P102i is title of (has title): E71 Man-Made Thing
More precisely, only the inverse properties where the domain and range
differ should be added, i.e. there is no need to repeat symmetric
properties (e.g. P121 "overlaps with"), transitive asymmetric properties
(e.g. P5 "consists of"), or the dynamic asymmetric property P139 "has
alternative form".
Example E3 Condition State: add the inverse properties
P35i was identified by (has identified): E14 Condition Assessment
P44i is condition of (has condition): E18 Physical Thing
but not P5i since the transitive property P5 is already listed
The Primitive Values are an exception since properties with range E60
Number, E61 Time Primitive, and E62 String have no inverse properties.
For these entities it makes sense to list the "normal" properties that
lead to them.
Example E60 Number: add the properties
E19 Physical Object. P57 has number of parts: E60
E54 Dimension. P90 has value: E60
Wolfgang
