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> on behalf of Martin
Doerr <mar...@ics.forth.gr>
*Date: *Thursday, August 2, 2018 at 8:55 AM
*To: *crm-sig <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 |
|
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 |
--------------------------------------------------------------
