Can rico:Coordinates be replaced by CRMgeo SP15 Geometry ?

[akuckartz]

See

• https://www.cidoc-crm.org/crmgeo/sites/default/files/CRMgeo1_2.pdf
• https://www.ica.org/standards/RiC/RiC-O_v0-2.html#Coordinates

In any case coordinates (point geometries) are only a subset of geometries and there should be good reasons for such a restriction.

[ivozandhuis]

I am not aware of this particular geo-standard, but personally I would study whether you could combine the two. Would it be possible to capture the geo-data of a rico:Place by adding properties from the CRMgeo-model?

[florenceclavaud]

Hi @akuckartz and @ivozandhuis , I do not know this extension of CRM either, however I would say (my two first cents):

• unless I am wrong it is a proposal dated 2015; has it been approved?
• anyway, as I already said in another comment, EGAD will not for now, at least not before RiC-O 1.0 (to be released by October) work on articulating RiC-O to any other ontology; we first need to finish a complete, consistent version, and we still have a lot to do
• here at the AnF we have already semantized using RiC-O, many descriptions of places, among which some have Coordinates, that may be points or geometries. For this we use either rico:latitude and rico:longitude, or rico:measure, with datatype http://www.opengis.net/ont/geosparql#wktLiteral.

[VladimirAlexiev]

Hi @florenceclavaud ! Thanks for using GeoSPARQL, this is the best way! But I think it's not RICO's role to be defining geo properties. So A couple of considerations:

• instead of rico:longitude, latitude can it use wgs:long, lat? This simple ontology has existed for 20 years
• According to GeoSPARQL, you need a geo:Geometry node that can hold different equivalent representations, eg geo:asWKT, geo:asGML. Is it possible to have such node in RICO? If so, the incoming link should be geo:hasGeometry not rico:measure

[florenceclavaud]

rico:measure can be used for any rico:Thing, not only for places.

We for now, at the AnF, are using the rico:Coordinates class as follows, where rico:measure has a rdf:datatype (just an example, quickly picked):

<rico:Coordinates rdf:about="coordinates/FRAN_RI_005-d3ntcnfgcw--pvic5jinawzd-202003-WGS84">
      <rico:isOrWasCoordinatesOf rdf:resource="physicalLocation/FRAN_RI_005-d3ntcnfgcw--pvic5jinawzd-2020"/>
       <rico:measure rdf:datatype="http://www.opengis.net/ont/geosparql#wktLiteral">MULTIPOLYGON[[[2.296869638468005, 48.8735484315143], [2.2968813746201167, 48.87354478436745], [2.296882298769853, 48.87354601290201], [2.2968941329632924, 48.87354227369754], [2.296893380003215, 48.873541089337046], [2.296908431453953, 48.87353616211061], [2.2969090775980527, 48.87353717946518], [2.296938510989417, 48.873527634045416], [2.296937694100348, 48.87352643851761], [2.296950301197278, 48.87352260761749], [2.296951024308211, 48.8735236802838], [2.296962356713552, 48.873520046046515], <!-- etc. etc. -->]]]</rico:measure>
      <rico:geodesicSystem>WGS84 [http://data.ign.fr/id/ignf/crs/WGS84G]</rico:geodesicSystem>
</rico:Coordinates>

I do not mean at all this is the only way to do so. I agree that some people may prefer to use geoSPARQL geometry directly, and maybe this could be discussed within EGAD; in such a case we will need to align RiC-O classes and properties with GeoSPARQL, or at least to document how you can combine both.

Anyway, in our domain, we consider places are geo-historical entities, with a description, a history, chronological relations, 1 to many names possibly known at some dates, types that can change, relations to agents, etc... So RiC-O 1.0 includes a quite rich model for places, where you can find and use rico:Coordinates if you want.

[VladimirAlexiev]

IMHO it is not RiCO's place to to define representation of geometries. That is the role of OGC (makers of GeoSPARQL). I see the following problems above (in addition to the use of custom properties that was already discussed:

• These are not valid WKT literals: those use round parentheses and fewer commas. See examples at https://rdrr.io/cran/wellknown/man/lint.html and https://rdrr.io/cran/wellknown/man/multipolygon.html
• geodesicSystem is a bit imprecise: OGC calls this Spatial Reference System (SRS) or CoordinateReferenceSystem (CRS) or GeodeticCRS
• You should use only use CRS URLs in the http://www.opengis.net/def/crs/ namespace.
  • http://data.ign.fr/id/ignf/crs/WGS84G returns some data but it's not enough to perform CRS transformations, and I doubt it is known in geospatial software (eg PostGIS and semantic repositories)
  • In contrast, http://www.opengis.net/def/crs/OGC/1.3/CRS84 returns rich XML information that can be used for transformations
• http://www.opengis.net/def/crs/OGC/1.3/CRS84 is the default CRS and you don't need to specify it
• If you want to specify a different CRS, you need to do it at the beginning of the WKT literal, not as a separate property. Here is an example from page 17 of GeoSPARQL 1.0 (doc OGC 11-052r4, released in 2012)

  "<http://www.opengis.net/def/crs/EPSG/0/4326> Point(33.95 -83.38)"^^<http://www.opengis.net/ont/geosparql#wktLiteral>

• rdf:about, rdf:resource use relative URLs: but does the file define xml:base for them to be unambiguous?

[williamsonrichard]

Just to chime in regarding...

instead of rico:longitude, latitude can it use wgs:long, lat?

and...

IMHO it is not RiCO's place to to define representation of geometries

...I do not necessarily agree here :-). If a concept is important enough for the context of an archival description, it can be very useful to bring it into RiC-O, so that archivists have a common vocabulary for that concept. What RiC-O should not do is try to define the specifics of a non-archival concept, and it indeed does not do this: in the examples under discussion here, for example, it does not try to say what a longitude or a measure, etc, actually is.

For a precise example, if we disregard the fact that WGS is not expressed in OWL (i.e. we work in OWL Full), then if one wishes to say that a longitude is to be understood in the WGS sense, one can always do something like the following when defining one's own ontology on top of RiC-O:

Class: Coordinates
  SubClassOf: rico:Coordinates, wgs:Point

DataProperty: longitude
  SubPropertyOf: rico:longitude, wgs:long  

[florenceclavaud]

* `rdf:about, rdf:resource` use relative URLs: but does the file define `xml:base` for them to be unambiguous?

Yes of course we use xml:base. I had just copied/pasted a bit of code from one of our larger RDF files. Thanks for your other comments @VladimirAlexiev, we will check all this and fix what is wrong in our dataset, which is a work in progress, which used external quite reliable, but also old now, datasets, particularly as concerns the round parentheses and commas. However I think we will keep the model we have for places in RiC-O for now ;-)

[florenceclavaud]

OK, I am closing this issue now as we found how to fix our data. Thanks @VladimirAlexiev and @tfrancart!

[VladimirAlexiev]

@williamsonrichard Just like OGC do not attempt to define archival standards, the RiCO people should not attempt to define geospatial standard/properties/representations. To each his specialty!

[florenceclavaud]

Hi @VladimirAlexiev, as the lead of RiC-O development team in ICA/EGAD and as a person who extensively uses RiC-O and also knows the archival landscape (since I am an archivist with technical skills, working on digital projects and particulary metadata since about 30 years), I actually agree with @williamsonrichard for now. We (obviously) do not want to replace geospatial standards with RiC-O; we are not geographers nor geomaticians. But we have to describe places when we describe archival resources. We need to describe them from our domain perspective, i.e. as past or present geo-historical entities of many various kinds, having or not one to many known physical locations through time, whose coordinates are known or not, having a history, changing names, related to other places (including chronologically), to agents (for example a place can be the jurisdiction of a corporate body), to records, to events, etc. etc. So geospatial standards are not enough for this. We also need a domain model that we can manage and maintain by ourselves with and for the archival community. I do not mean at all that we will not map RiC-O with other ontologies, or suggest a way to use RiC-O in combination with other ontologies, like PREMIS, CRM, or PROV-O, and GeoSPARQL. This is one of our top priorities now that we have a 1.0 version of RiC-O. We are going to do so as much as possible. Also, as concerns the datasets we have about places at the Archives nationales de France, we also already have started to align them with other datasets coming from geographers/geomaticians. See for example the ALEGORIA project. But we are using the RiC-O classes and properties to describe places, their locations on earth and the coordinates of those locations. Now we know what is wrong in our use of geoSparql wktLiteral, thanks to you and @tfrancart, we will fix our data.

[williamsonrichard]

@VladimirAlexiev I would argue that 'define' is not the correct term for what is done in RiC-O :-). As I wrote, RiC-O never says what any of these concepts actually is, it only introduces them into the archival vocabulary, as Florence describes in her comment just now. Thus I would say that 'recognises (the importance of in the archival domain)' or something would be a more accurate term :-).