Dear All,
My impression is that the issue is too complex to result in a simple set
of foundational relations, and we lack the expertise. There is a
thematic series in the ER Conferences about spatial reasoning, a small
part of which I have seen,
with an immense diversity of models. I'd recommend not to continue
discussion without an expert in this area, or someone reading into it.
The relations Christian-Emil lists below are foundational terms of
topology, with clear logical definitions.
I would also argue, that "over", "under" has no relevance for querying
integrated data sets, but is relevant to locally confined, specialized
reasoning. I argue therefore, that is is out of scope.
If there could be found a general notion of geometric closeness, that
may be important in order to retrieve datasets that may contain more
detailed topological terms in other representational frameworks.
The question what is not a stratigraphic unit I regard as important, and
I'd recommend to discuss your observations with archaeologists in the
next Meeting.
All the best,
Martin
On 2/4/2020 10:00 PM, Christian-Emil Smith Ore wrote:
Dear all,
In the Berlin November meeting 2018, I suggested that one should
generalize 'AP11 has physical relation' from CRMarcheo to CRMsci so
that it could be used for all layered structures but also for cuts
done in archaeological excavations. It became clear during the
discussion that the scope of 'AP11 has physical relation' was
strictly limited to the physical relation between layers and surfaces
observed in archaeological excavations. The AP11.1 is used to type
the relation e.g. over, under, mortar layers, one structure modified
by another (eg a grave cut into another grave etc.), that is, every
relation that can be used as the basis for the chronology of the layers.
The remaining issue is how to model the physical relations between
physical objects/features which are not naturally modelled as
instances of 'A8 Stratigraphic Unit'. In many of the 597
archaeological excavations sets I have analysed there are objects and
features which I hesitate to model as instances of 'A8 Stratigraphic
Unit' like modern structures natural formations, roots etc.
Some relations can be expressed indirectly through the location of the
objects, that is, by the properties of E53 Space:
P89
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_P89_falls_within> falls
within (contains): E53
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_E53_Place> Place
P121
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_P121_overlaps_with> overlaps
with: E53
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_E53_Place> Place
P122
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_P122_borders_with> borders
with: E53
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_E53_Place> Place
P157
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_P157(Px2)_is_at> is
at rest relative to (provides reference space for): E18
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_E18_Physical_Thing> Physical
Thing
P168
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_P168_place_is> place
is defined by (defines place) : E94
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_E94_Space_Primitive> Space
Primitive
P171
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_P171_at_some> at
some place within : E94
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_E94_Space_Primitive> Space
Primitive
P172
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_P172_contains> contains
: E94
<file:///M:/cidoc-crm/2020/CIDOC%20CRM_v6.2.7_Definition_esIP.docx#_E94_Space_Primitive> Space
Primitive
There is no property about a general relative position of two
instances of E53 Place. It is hard to see how to model the standard
spatial relations like 'over' and 'under' we find in the
documentation. Most of the documentation (I have seen) is about
situations on Earth, where up and down is determined by the
gravitation. One could argue that the documentation should contain
x,y,z coordinates, but it does not always do, especially documentation
earlier then 1990. The problem is similar to the temporal ordering,
where the issue is easier since it is one-dimensional.
I am happy if somebody could point to a solution in the CRM. If not
we should make this into an isssue.
Best,
Christian-Emil
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
------------------------------------
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: mar...@ics.forth.gr
Web-site: http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
