Is that all correct?
Many thanks,
Rob
PS. FWIW, I use this tool to generate the WKT:
https://boundingbox.klokantech.com/
*From: *Martin Doerr <mar...@ics.forth.gr>
*Date: *Friday, August 3, 2018 at 8:50 AM
*To: *Robert Sanderson <rsander...@getty.edu>, crm-sig
<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:
oAssociating 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.
oThe 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?
oThere 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.
oRelationships 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 |
--------------------------------------------------------------
