[Crm-sig] Issue 479 Homework

Martin Doerr martin at ics.forth.gr
Thu Jun 17 15:55:26 EEST 2021


Dear All

I propose to formulate 479 as: Publishing the table of top properties of 
all extensions from issue 469, define a format/style for declaring 
non-covered top properties in the textual extension definitions, and and 
allow extensions to refer to high level top properties from CRMbase from 
another CRM extension,. This needs a sort of circularity control.

Background:

In the introduction of CRM7.1.1, it is stated:

*"Mechanism 4*, conservative extension, is more complex:

With increasing use of the CIDOC CRM, there is also a need for 
extensions that model phenomena from a scope wider than the original one 
of the CIDOC CRM, but which are also applicable to the concepts that do 
fall within the CIDOC CRM’s scope. When this occurs, properties of the 
CIDOC CRM may be found to be applicable more generally to superclasses 
of the extension than to those of their current domain or range in the 
CIDOC CRM. This is a consequence of the key principle of the CIDOC CRM 
to model “bottom up”, i.e., selecting the domains and ranges for 
properties to be as narrow as they would apply in a well understood 
fashion in the current scope, thus avoiding making poorly understood 
generalizations at risk of requiring non-monotonic correction.

The fourth mechanism for extending the CIDOC CRM by conservation 
extension can be seen to be split into two cases:

1A new class or property is added to an extension of the CIDOC CRM, 
which is not covered by superclasses other than E1 CRM Entity or a 
superproperty in the CIDOC CRM respectively. In this case, all facts 
described only by such concepts are not accessible by queries with CIDOC 
CRM concepts. Therefore, the extension should publish in a compatibility 
statement the additional relevant high-level classes and properties 
needed to retrieve all facts documented with the extended model. This 
case is a monotonic extension.

2The domain or range of an existing property in the CIDOC CRM is changed 
to a superclass of the one or the other or both, because the property is 
understood to be applicable beyond its originally anticipated scope. In 
this case, all facts described by the extension are still accessible by 
querying with the concepts of the CIDOC CRM, but the extension can 
describe additional facts that the CIDOC CRM could not. This case is a 
monotonic extension and generally recommended, because it enables 
bottom-up evolution of the model. If this change is part of a new 
release of the CIDOC CRM itself, it is simply backwards compatible, and 
this has been done frequently in the evolution of this model.

"

Best,

Martin


-- 
------------------------------------
  Dr. Martin Doerr
               
  Honorary Head of the
  Center for Cultural Informatics
  
  Information Systems Laboratory
  Institute of Computer Science
  Foundation for Research and Technology - Hellas (FORTH)
                   
  N.Plastira 100, Vassilika Vouton,
  GR70013 Heraklion,Crete,Greece
  
  Vox:+30(2810)391625
  Email: martin at ics.forth.gr
  Web-site: http://www.ics.forth.gr/isl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210617/c9e0f934/attachment-0001.html>


More information about the Crm-sig mailing list