Dear Martin, Rob and All, Thanks very much for elaborating on the issues related to Space Primitives. I would like to add/emphasis some off the points Rob and Martin made: Properties and Provenance of Declarative Places: I believe Martins approach to relate these relations to the E53 Place (defined by (P168) an E94) and not the E94 is a good choice as the recording of the Properties and Provenance of Declarative Places becomes increasingly important when having multiple geometries (coming from multiple sources and thus multiple methods to create the geometry) that approximate one phenomenal place. For different applications and reasonings I need to know more about the declarative place (Geometry) and its provenance and type. An example: Right now I am working on the integration of several different Gazetteers and I need to record the provenance and type of the geometry in order to make a decision which geometry to use as preferred or for a specific purpose. Formats of serialisation: One goal of CRMgeo was to relate CIDOC CRM to OGC GeoSPARQL and thus make use of the developments and standards of OGC. In OGC GeoSPARQL one goal for further work was to enhance the specific serialisation formats, explicitly stating KML and GeoJson. Unfortunately GeoSPARQL did not evolve quickly, although it is still discussed (https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL) and serialisation is a major issue. Nevertheless GeoSPARQL offers a general property GeoSPARQL:#hasSerialization that allows for encoding in serialisations different to WKT or GML. The type of the encoding would then probably needed to be stated in a P2_has_type of the E53. Another option may be to create specific subproperties of GeoSPARQL:#hasSerialization in a new version of CRMgeo. (please comment) Relationships between geometries: When geometries are treated as declarative Places and in CRMcore as E53 the spatial relationships of CRM are available. Through the linking to GeoSPARQL the topological relations of GeoSPARQL are available as well. In the paper "CRMgeo: A spatiotemporal extension of CIDOC-CRM" (attached, https://link.springer.com/article/10.1007/s00799-016-0192-4) we provided some graphics showing the relations of CRMgeo and GeoSPARQL and in figure 4 and 5 you see that the topological properties of GeoSPARQL are available CRM Places if you need richer topological relations.
A comment on the example of Rob:
_:rob a E21_Person ;
rdfs:label “Rob” ;
p98i_was_born [
a E67_Birth ;
p7_took_place_at [
a E53_Place ;
rdfs:label “Rangiora” ;
q11i_approximated_by [
a SP6_Declarative_Place ;
p2_has_type <xxx:Geospatial_Bounding_Box> ;
rdfs:label “Bounding Box for Rangiora” ;
P168_place_is_defined_by “POLYGON((172.565456 -43.285409, 172.622116
-43.285409, 172.622116 -43.323697, 172.565456 -43.323697, 172.565456
-43.285409))”
]
]
] .
And further SP6s could be introduced for other approximations, such as
centroids, points, exact boundaries, different coordinate systems, etc.
I had interpreted the footnote that SP6 would also be collapsed into Place,
which I understand not to be the case now.
Given that I was only born at one location, the E53 provides the unique
reference, and SP6 provides the ability to have different approximations of
that location. If only one approximation was needed, then E53 and SP6 could be
collapsed, as SP6 is a subclass of E53. (Though that doesn’t seem like a good
idea…)
E53 provides the unique reference:
I would interpret the E53_Place in the example as Rangiora the town and not
the spatial projection(P161) of the spacetime volume(E92) of the birth event
(E67), which is a much smaller place and unique.
The birth place and Rangiora are two distinctive places with the topological
relation that one falls within the other.
Best,
Gerald
From: Crm-sig
<crm-sig-boun...@ics.forth.gr<mailto:crm-sig-boun...@ics.forth.gr>> on behalf
of Martin Doerr <mar...@ics.forth.gr<mailto:mar...@ics.forth.gr>>
Date: Friday 3 August 2018 at 17:50
To: Robert Sanderson <rsander...@getty.edu<mailto:rsander...@getty.edu>>,
crm-sig <Crm-sig@ics.forth.gr<mailto:Crm-sig@ics.forth.gr>>
Subject: Re: [Crm-sig] NEW ISSUE: Harmonizing Space Primitive
Dear Robert,
Thank you for your quick comments!
Your comments well taken, I agree with all the needs you specify, but I would
like to point you to a confusion between a place defined by a geometry and the
place defined by natural features, that are approximated by places defined by
geometry. It was the particular achievement of Gerald Hiebel's analysis to make
this distinction. I kindly ask you to read his papers, if my explanations here
are not clear enough:
1. Hiebel, G.H, Doerr, M. (2013). Aspects of integrating geoinformation in
Digital Libraries (Session S32, 669)<http://caa2013.org/drupal/sessions>.
Computer Applications and Quantitative Methods in Archaeology (CAA) 2013,
Perth-Australia, 25th -28th March 2013.
2. Hiebel, G.H, Doerr, M., & Eide, Ø. (2013). Integration of CIDOC CRM with
OGC Standards to model spatial information (Session5,
522)<http://caa2013.org/drupal/sessions>. Computer Applications and
Quantitative Methods in Archaeology (CAA) 2013, Perth-Australia, 25th -28th
March 2013.
(pdf<https://www.ics.forth.gr/_publications/CAA2013_Hiebel_Doerr_Eide_CIDOC_CRM_OGC.pdf>).
3. Doerr, M., & Hiebel, G.H (2013). Where did the Varus battle take place? -
A spatial refinement for the CIDOC CRM ontology
(ID:760)<https://www.conftool.com/wac7/index.php?page=browseSessions&form_session=150&metadata=show>.
Seventh World Archaeological Congress, The Dead Sea, Jordan, January 13th -
18th 2013.
4. Doerr, M., & Hiebel, G.H (2013). CRMgeo: Linking the CIDOC CRM to
GeoSPARQL through a Spatiotemporal Refinement.
2013.TR435_CRMgeo_CIDOC_CRM_GeoSPARQL.pdf<https://www.ics.forth.gr/tech-reports/2013/2013.TR435_CRMgeo_CIDOC_CRM_GeoSPARQL.pdf>.
In more detail:
On 8/2/2018 8:50 PM, Robert Sanderson wrote:
Martin, all,
I feel that the implications of your footnote are somewhat problematic. I agree
overall with the clarifications but, SP4/SP5 add extra value.
In particular:
· Use of literals prevents the association of additional information
with the value, other than the custom datatype, especially:
o Associating P2_has_type is enormously useful to give guidance on the usage
for the particular geometry. Types might distinguish simple bounding boxes for
user interfaces from very accurate geo-political boundary data that would be
useful for calculations. Or coastlines from other boundaries. Preferred from
alternative.
All these are examples of "declarative places". The simple bounding box, the
centroid, the representation of a coastline, all are places. The coastline
itself, is another, a phenomenal place. Therefore, the distinctions you are
making here are about the quality of approximation between a phenomenal and a
declarative place (Q11 approximates). They are not a property of the geometric
place expression. In my opinion, the only property geometric place expressions
have is the type of encoding. The exactly same geometry can be defined with
different encoding types. The encoding type however is embedded in the XML
datatype already, so there is no need to create an intermediate URI. We had
cases in which it was registered which encoding a GPS device created, and which
encoding was a translation of the former. In both cases, the device measured
the same Place. I'd argue that this is not enough reason to reify the encoded
string itself.
o The source / provenance of the data is very important. Is this a bounding
box that someone threw together, or data that is provided by an established
authority?
Again, these are properties of the declarative place. How was it defined and
why? If, what you attribute to an instance of SP5, you would attribute to an
instance of E53 Place.P168...E94, we are talking exactly about the same
information, isn't it?
o There are more formats than just WKT and GML. GeoJSON and KML are very
frequently used, and there are many more besides those. Not all formats have
the capacity to embed the reference system within the literal.
No problem, use "P157 is at rest relative to (provides reference space for)"
for the declarative place, or a suitable type.
o Relationships between geometries are also useful, such as partitioning.
Right, these are topological relations, and not relations between encodings.
They hold for the mathematical space defined, and do not differ from encoding
to encoding. So, they are relations between E53 Places, and we have a lot of
them in CRMbase and CRMgeo.
· Literals can only be embedded within the serialized graph, rather
than referenced externally. This means that the coastline of New Zealand (a
100+ mb file) would need to be embedded within the description of the E53
Place, rather than being referenced.
Again: The coastline of New Zealand is a fuzzy, rough thing of infinite length.
Any representation is a Place in its own right, related by Q11 to the real
coastline. All properties you require should be there.
If you feel my text (not the foot note) does not make it clear enough that each
geometry expression defines a PLace in its own right, distinct from the Place
it was made to approximate, please propose additional wording:-).
Conversely a resource can have a URI and optionally a value, providing
flexibility within a single model.
· Relying on subproperties to manage the data type runs into the
extensibility problem above. We would need to continually create new properties
when there are new data types.
Right. They are redundant, because the XML datatypes identify themselves. The
query for a different property may be sometimes more convenient than querying
for the datatype found in the Literal.
A cognate situation is rdfs:label vs E41 Appellation – label is great if you
have very simple data, but E41 provides clear advantages when you want to do
more than just display a string to a user. Having a single literal (be it a
label or geometry) is great for the simple cases, but rdfs:label does not
obviate the need for E41.
I agree!!
Nor should P168 obviate the need for a richer spatial system.
I argue that this is different. Geometric Place Expressions do not have a rich
cultural history as names do (Martinus, Marty, Μαρτίνος, Αριανός....)
and the Place is not the Expression.
The devil is in the detail: OWL does not like classes which have either URIs or
data values as instances. Therefore I argue not to make more of these
constructs.
The problem with Appellation is already big enough.
Opinions?
Martin
Rob
From: Crm-sig
<crm-sig-boun...@ics.forth.gr><mailto:crm-sig-boun...@ics.forth.gr> on behalf
of Martin Doerr <mar...@ics.forth.gr><mailto:mar...@ics.forth.gr>
Date: Thursday, August 2, 2018 at 8:55 AM
To: crm-sig <Crm-sig@ics.forth.gr><mailto:Crm-sig@ics.forth.gr>
Subject: [Crm-sig] NEW ISSUE: Harmonizing Space Primitive
Dear All,
I have just finished a draft of the section "recording space" of the guideline
"Expressing the CIDOC CRM in RDF
(https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit#<https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit>):
The recommended datatypes of
RDF1.1 do not contain datatypes for describing geometric entities on the
surface of earth. On the other side, they become increasingly important, and
the CIDOC CRM version 6.2 on defines E94 Space Primitive, subclass of: E59
Primitive Value, as:
“This
class comprises instances of E59 Primitive Value for space that should be
implemented with appropriate validation, precision and references to spatial
coordinate systems to express geometries on or relative to earth, or any other
stable constellations of matter,
relevant to cultural and scientific documentation.
An E94 Space Primitive defines
an E53 Place in the sense of a declarative place as elaborated in CRMgeo (Doerr
and Hiebel 2013), which means that the identity of the place is derived from
its geometric definition. This declarative place allows for the application of
all place properties
to relate phenomenal places to their approximations expressed with geometries.
Definitions of instances of
E53 Place using different spatial reference systems always result in
definitions of different instances of E53 place approximating each other. It is
possible for a place to be defined by phenomena causal to it, such as a
settlement or a riverbed, or other
forms of identification rather than by an instance of E94 Space Primitive. Any
geometric approximation of such a place by an instance of E94 Space Primitive
constitutes an instance of E53 Place in its own right, i.e., the approximating
one.
Instances of E94 Space Primitive
provide the ability to link CRM encoded data to the kinds of geometries used in
maps or Geoinformation systems. They may be used for visualisation of the
instances of E53 Place they define, in their geographic context and for
computing topological relations
between places based on these geometries.
E94
Space Primitive is not further elaborated upon within this model. Compatibility
with OGC standards are recommended.”
These
standards currently do not have a common form comprising all others. Further,
geometries defined with respect to particular object shapes, such as
rotationally symmetric ones, are possibly open ended.
Therefore
we define in the CRM RDFS the range of properties that use E94 Space Primitive
in the definition of the CRM as
rdfs:Literal, and recommend the user to instantiate it with adequate XML
datatypes. These are for the surface of Earth “ogc:gmlLiteral”
or “geo:wktLiteral”.
In
the current version of the CIDOC CRM, only the property “P168 place is defined
by (defines place)” has range E94 Space Primitive.
Since
any instance of E94 Space Primitive identifies unambiguously an instance of E53
Place by a symbolic expression,
E94 Space Primitive must logically be regarded as a subclass of E41
Appellation, regardless whether this can be expressed in RDFS or OWL. See below
for the relationship between datatypes an E41 Appellation.
In a footnote I make the argument that:
"The concepts E47 Spatial Coordinates,crmgeo: SP5 Geometric Place Expression,
crmgeo:Q10 defines place and P168 place is defined by (defines place) need to
be revised soon.
E94 Space Primitive should replace E47 Spatial Coordinates and SP5 Geometric
Place Expression.P168 place is defined by (defines place) should replace
crmgeo:Q10 defines place. It may be useful in the CRM RDFS to specify two
subproperties of P168, one having as range “geo:wktLiteral” and another
“ogc:gmlLiteral”.
Best,
Martin
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email:
mar...@ics.forth.gr<mailto:mar...@ics.forth.gr> |
|
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 |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email:
mar...@ics.forth.gr<mailto:mar...@ics.forth.gr> |
|
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 |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
Hiebel2017_Article_CRMgeoASpatiotemporalExtension.pdf
Description: Hiebel2017_Article_CRMgeoASpatiotemporalExtension.pdf
