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: [email protected]
Web-site: http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
