[Crm-sig] Cidoc 5.1 draft: also list inverse properties for each entity
wolfgang.schmidle at uni-koeln.de
Mon Nov 19 12:42:15 EET 2012
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.
Am 18.11.12 18:52, schrieb martin:
> Dear Wolfgang,
> Have you seen this:
> 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.
> 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
More information about the Crm-sig