Findspot is not visible in numishare cointype map

Question

Findspot is not visible in numishare cointype map

Opened this issue 3 years ago · 4 comments

I have setup a collection with coins with a findspot (example "Berlin (Germany)" whichs links to "https://www.geonames.org/2950159/berlin.html" and notes in the xml as "https://sws.geonames.org/2950159/").
The numishare collection shows the location of the findspot in the map in the public site . The mint location is displayed as well.
So, the basic settings like "Geonames Username", "Mapbox Access Token" seem to be ok.

Now, I have setup a cointype instance as well using the same basic settings "Geonames Username", "Mapbox Access Token".
As an example one cointype has a URI:

"http://localhost:10200/orbeon/numishare/koeln/id/koeln.2.eb_koeln.0470"

Ok, now let us assume "http://numismatics.org/collection/1960.111.27" is a spicemen of the above cointype (that is not really the case, just as an example). Let assume the coin was found in "Berlin (Germany)" like the one above.

Now, I used the following procedure to get the ANS coin displayed as a spicemen in the cointype instance (all as an example):

Create VoID RDF of Mantis by using: "http://numismatics.org/search/nomisma.void.rdf"
Create RDF of the spicemen by using: "http://numismatics.org/collection/1960.111.27.rdf"
Edit 1960.111.27.rdf and add the lines in the nmo:NumismaticObject section:
<nmo:hasFindspot rdf:resource="https://sws.geonames.org/2950159/"/>
<nmo:hasTypeSeriesItem rdf:resource="http://localhost:10200/orbeon/numishare/koeln/id/koeln.2.eb_koeln.0470"/>
Login to fuseki and upload the files 1960.111.27.rdf and nomisma.void.rdf
Check the thumbnails of the cointype ui: "http://localhost:10200/orbeon/numishare/koeln/results". The thumbnail of the ANS coin is displayed next to cointype koeln.2.eb_koeln.0470. That is good. Now click on the link for the cointype to get the details displayed. At the bottom it shows the examples of this type (1960.111.27). On the right it shows a map, but showing the mint location only. The findspot is not visible.

Ok. "maybe" the findspot information need to be in the source instance (here Mantis). I don't know if this is required.
So I tried the same with the coin in my own instance which is mentioned at the top.

Create VoID RDF
create RDF of spicemen. No need to add lines because it is already in the RDF (hasFindspot, hasTypeSeriesItem).
Login to fuseki and upload both files.
When I browse the cointype instance, I do see the just added spicemen next to the ANS one, which is good. But still the map does not show the findspot in the map.

Am I doing something wrong?
Any hint is welcome.

Answer 1 · 2021-12-29T15:23:09.000Z

Just some invesitgations from my side (you can ignore them):

Made a test in the cointype UI for the cointype with several spicemen:

http://localhost:10200/orbeon/numishare/koeln/id/koeln.2.eb_koeln.0470?lang=en

Click on "Download CSV" in area "Examples of this type". The csv-list shows empty fields for "findUri,findspot".
I observed that the query for the sparql endpoint (URL-encoded) looks like:

PREFIX rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX crm:	<http://www.cidoc-crm.org/cidoc-crm/>
PREFIX dcterms:  <http://purl.org/dc/terms/>
PREFIX nm:       <http://nomisma.org/id/>
PREFIX nmo:	<http://nomisma.org/ontology#>
PREFIX skos:      <http://www.w3.org/2004/02/skos/core#>
PREFIX foaf:	<http://xmlns.com/foaf/0.1/>
PREFIX rdfs:	<http://www.w3.org/2000/01/rdf-schema#>
PREFIX void:	<http://rdfs.org/ns/void#>
PREFIX geo:	<http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX edm: <http://www.europeana.eu/schemas/edm/>

SELECT DISTINCT ?object ?title ?identifier ?findUri ?findspot ?hoard ?collection ?publisher ?dataset ?datasetTitle ?weight ?axis ?diameter ?obvThumb ?revThumb ?obvRef ?revRef ?comThumb ?comRef ?obvManifest ?revManifest ?comManifest ?model WHERE {
{ ?object a nmo:NumismaticObject ;
 nmo:hasTypeSeriesItem <http://localhost:10200/orbeon/numishare/koeln/id/koeln.2.eb_koeln.0470>}
UNION { <http://localhost:10200/orbeon/numishare/koeln/id/koeln.2.eb_koeln.0470> skos:exactMatch ?match .
?object nmo:hasTypeSeriesItem ?match ;
  a nmo:NumismaticObject }
UNION { ?broader skos:broader+ <http://localhost:10200/orbeon/numishare/koeln/id/koeln.2.eb_koeln.0470> .
?object nmo:hasTypeSeriesItem ?broader ;
  a nmo:NumismaticObject }
UNION { ?broader skos:broader+ <http://localhost:10200/orbeon/numishare/koeln/id/koeln.2.eb_koeln.0470> .
?broader skos:exactMatch ?match .
?object nmo:hasTypeSeriesItem ?match ;
  a nmo:NumismaticObject }
?object dcterms:title ?title .
OPTIONAL { ?object dcterms:identifier ?identifier}
OPTIONAL { ?object nmo:hasCollection ?colUri .
?colUri skos:prefLabel ?collection FILTER(langMatches(lang(?collection), "EN"))}
?object void:inDataset ?dataset .
?dataset dcterms:publisher ?publisher FILTER (lang(?publisher) = "" || langMatches(lang(?publisher), "en")) .
?dataset dcterms:title ?datasetTitle FILTER (lang(?datasetTitle) = "" || langMatches(lang(?datasetTitle), "en")) .
OPTIONAL{ ?object nmo:hasFindspot/crm:P7_took_place_at/crm:P89_falls_within ?findUri .
  ?findUri a crm:E53_Place ;
  rdfs:label ?findspot }
OPTIONAL {?object dcterms:isPartOf ?hoard .
 ?hoard a nmo:Hoard ;
 	skos:prefLabel ?findspot FILTER(langMatches(lang(?findspot), "EN")) }
OPTIONAL { ?object nmo:hasWeight ?weight }
OPTIONAL { ?object nmo:hasAxis ?axis }
OPTIONAL { ?object nmo:hasDiameter ?diameter }
OPTIONAL { ?object foaf:thumbnail ?comThumb }
OPTIONAL { ?object foaf:depiction ?comRef 
	OPTIONAL { ?comRef dcterms:isReferencedBy ?comManifest }}
OPTIONAL { ?object nmo:hasObverse/foaf:thumbnail ?obvThumb }
OPTIONAL { ?object nmo:hasObverse ?obverse .
?obverse foaf:depiction ?obvRef
	OPTIONAL { ?obvRef dcterms:isReferencedBy ?obvManifest }}
OPTIONAL { ?object nmo:hasReverse/foaf:thumbnail ?revThumb }
OPTIONAL { ?object nmo:hasReverse ?reverse .
?reverse foaf:depiction ?revRef 
	OPTIONAL { ?revRef dcterms:isReferencedBy ?revManifest }}
OPTIONAL {?object edm:isShownBy ?model}
} ORDER BY ASC(?publisher) ASC(?datasetTitle)

So the code expects something with:

nmo:hasFindspot/crm:P7_took_place_at/crm:P89_falls_within and crm:E53_Place.

I have seen something similar here: http://numismatics.org/chrr/id/BOU.rdf which has a part like:

<nmo:hasFindspot>
<nmo:Find>
<crm:P7_took_place_at>
<crm:E53_Place>
<rdfs:label xml:lang="en">Bourgueil, France</rdfs:label>
<crm:P89_falls_within rdf:resource="https://sws.geonames.org/3030944/"/>
</crm:E53_Place>
</crm:P7_took_place_at>
</nmo:Find>
</nmo:hasFindspot>

I added this into my rdf file and uploaded it in fuseki. But still the findspot is not visible in the ui.
OK, so I tried the above query directly in fuseki. It shows emtpy fields for "findUri,findspot".

It showed results if I modified the hasFindspot part like this:

OPTIONAL{ ?object nmo:hasFindspot/crm:P7_took_place_at ?myPlace .
  ?myPlace a crm:E53_Place .
  ?myPlace crm:P89_falls_within ?findUri ;
  rdfs:label ?findspot }

Maybe something is wrong with E53_Place data or query. But here my knowledge is not deep enough.

Answer 2 · 2021-12-29T15:54:50.000Z

I'm on holiday this week and will write up a detailed response next Monday. The short of it is that our findspot data model has evolved and more resembles the ARIADNE CIDOC CRM spec. The model has been discussed on the Nomisma Google Group but isn't publicly documented on the Nomisma site. I'll update this documentation next week.

You can see the example at http://coinhoards.org/id/igch0001.rdf includes the E53_Place that also needs to be uploaded into the endpoint.

Answer 3 · 2021-12-30T10:40:21.000Z

Ah! I see. Something like this was missing:

    <crm:E53_Place rdf:about="https://sws.geonames.org/7531264/">
        <rdfs:label>My Marienburg e35_place</rdfs:label>
        <crm:P2_has_type rdf:resource="http://vocab.getty.edu/aat/300008347"/>
        <geo:location rdf:resource="https://sws.geonames.org/7531264/#this"/>
        <crm:P168_place_is_defined_by rdf:resource="https://sws.geonames.org/7531264/#this"/>
    </crm:E53_Place>
    <geo:SpatialThing rdf:about="https://sws.geonames.org/7531264/#this">
        <rdf:type rdf:resource="http://www.ics.forth.gr/isl/CRMgeo/SP5_Geometric_Place_Expression"/>
        <crmgeo:Q9_is_expressed_in_terms_of rdf:resource="http://www.wikidata.org/entity/Q215848"/>
        <geo:lat rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">54.02846</geo:lat>
        <geo:long rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">19.04435</geo:long>
        <crmgeo:asWKT rdf:datatype="http://www.opengis.net/ont/geosparql#wktLiteral">POINT (19.04435 54.02846)</crmgeo:asWKT>
    </geo:SpatialThing>

At a first glance, this looks like much more effort to gather all the names and coordinates. But I will wait, maybe there is a best practice for it.

Enjoy your holiday! Thanks for your support.
See you next year.

Answer 4 · 2022-01-07T18:27:37.000Z

You've more or less uncovered it. The new model introduces some complexity, but resolves some problems we had early on with coins from the Portable Antiquities Scheme that had different geographic coordinates. There is updated documentation on the findspot model here: http://nomisma.org/documentation/contribute

And I have also made some updates to the SPARQL example pages to remove the deprecated spatial queries and update the query for findspots for RIC Augustus 1A with the updated structure.

Note that for data dumps being ingested into Nomisma.org, our back-end reconciles gazetteer URIs to Wikidata and constructs the crm:E53_Place and geo:SpatialThing automatically in order to resolve inconsistencies in harvesting datasets from different providers (that may use different gazetteer systems). But for your own purposes in your local SPARQL endpoint, you'll need to upload the E53_Place and SpatialThing nodes into your endpoint for the queries and visualizations to function correctly.