Dear Rob,
I am in a process to elaborate with Richard in more details the
relationships between rdfs:Literal , E59 Primitive Value and E41
Appellation.
We hope to have a viable text by the next CRM-SIG meeting.
The issue is that RDF 1.1 itself breaks the uniformity of a class system
overloading rdfs:Literal with xsd datatypes. The latter in turn cannot
be described by adequate superclasses in RDF, which is a logical
shortcoming of RDF and not a question of the CRM.
We have a need
A) to represent simple appellations by a Literal or alternatively by a
URI as formal instances of E41 Appellation when more has to be said
about it.
B) To represent all subclasses of E59 Primitive Value by various xsd
datatypes or even other custom datatypes.
Theoretically, time primitives, space primitives and spacetime
primitives denominate "loci" in the natural spacetime. As such, they are
indeed Appellations for such loci and *simultaneously "compactified"
instructions how to verify *the locus by distances relative to absolute
reference points. The latter makes them "primitive values".
We can identify rdfs:Literal with E59 Primitive Value, quite in the same
sense in which RDF1.1 does not make a distinction between literals that
identify a thing or spacetime locus and literals that do other things.
However, the mapping between xsd datatypes and Primitive Values is not
one-to-one. The xsd datatypes systematically represent smaller
mathematical spaces. For SP5, we have used instances such as gmlLiteral
or wktLiteral in projects.
Following these considerations, we should regard E94 Space Primitive a
subclass of E44 Place Appellation, and declare E47 as obsolete.
Since RDF is "tolerant" to typing violations and does itself not provide
a binding between specific xsd datatypes and respective property
semantics, if (!!) I am right, the question is, how best to connect
overloadings of rdfs:Literal with a CRM compatible class system.
The semantic gap has to be controlled at data entry time and be
interpreted correctly at query time, basically a task which we should
not invent, but which people that have implemented GIS-enabled triple
stores should have done before.
We'll revise this things in the near future.
In other words, P168 should have range rdfs:Literal, and only be used
with the respective data types that qualify as SP5 by their nature.
The fact, that the Literal instantiated as a range of P168 is an E94,
can be inferred automatically from the fact that P168 has been used,
assuming not been abused.
Opinions?
Best,
Martin
On 7/12/2018 12:28 AM, Hiebel, Gerald wrote:
Dear Rob, thanks very much for pointing out the issue, we will look
into it.
Best Gerald
Am 6. Juli 2018 01:45:58 schrieb Robert Sanderson <[email protected]>:
Dear all,
In the version 1.2 PDF [1] on page 10, it says that SP5 Geometric
Place Expression is a subclass of E94 Space Primitive. This allows it
to be referenced using P168 place is defined by.
However in the RDF encoding for CRM core, E94 is mapped to
rdfs:Literal which cannot also be used as a subclass with E73 and
E47. This is reflected in the RDF for CRMGeo by simply not including
E94 as a subclass.
So … the abstract documentation and the RDF mapping are significantly
inconsistent. Can an SP5 be used as the object of a P168 relationship
(and hence the mapping should be updated to include it) or not (and
hence the documentation should be updated to remove it)?
Many thanks!
Rob
[1] http://www.cidoc-crm.org/crmgeo/sites/default/files/CRMgeo1_2.pdf
Mit AquaMail Android
<https://play.google.com/store/apps/details?id=org.kman.AquaMail>
https://www.mobisystems.com/aqua-mail
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
