Places

[RGShepherd]

I suspect the following blocks aren't really necessary:

• classified_as (we just don't bother)
• referred_to_by
• member_of
• subject_of - could retain, but we always link form object to subject, and not vice versa - so probably not
• dimension
• made_of
• part
• current_owner
• current_custodian
• carries
• shows
• produced_by

It would be good to include coordinates for places, too, as we (will) have them: they would sit in defined_by. But the Linked Art specification is very thin on how to run a valid conversion for existing values (which sit in our coordinates block) to their adopted WKT standard. A Google search for 'convert latitude longitude to wkt' suggests that any solutions will be language-specific, so I suspect that this, too, is a question for K-Int.

[richardofsussex]

That output was produced by applying the Linked Art lens to data which is clearly intended to be JSKOS. My XSLT now specifies the JSKOS 'target' for places, with consequently a different outcome: http://richardofsussex.me.uk/ng/ciim7-output/place-39582.json.

This means that addition of coordinates will be under the aegis of JSKOS: https://gbv.github.io/jskos/jskos.html#location, rather than that of Linked Art. I'll have a go at mapping from your coordinates block and report back.

[richardofsussex]

OK, place-39582 now has a GEOJSON-conformant location: http://richardofsussex.me.uk/ng/ciim7-output/place-39582.json

[RGShepherd]

Coordinates look good, thanks. But I think we also have a problem with parents, as this entry should be polyhierarchical (with both Italy and Emilia as parents).

[richardofsussex]

It should ... This is the reverse of the one situation I have tested so far, concept-39977 (oil). There, both hierarchies have the same BT, so I took care to ensure it only appears once in the output. I'll work out why the second one is suppressed here.

As I write this, I realise that your parent block is already doing the suppression of duplicate BTs, so if I simply use that, all will be well in both situations. I can get rid of my complex XSLT key comparison, on the second-to-last members of the @hierarchy block!

[richardofsussex]

Should now be OK (as should concept-39977, just re-processed).

[RGShepherd]

Looking good - but alas, I think the current content of type should really be in @context? And does type have a place in SKOS?

[richardofsussex]

True: I hadn't found a context doc for JSKOS when I invented my own. Now switched over: http://richardofsussex.me.uk/ng/ciim7-output/concept-39977.json. (Type does have a place in SKOS, as a sub-class of Resource. However, we don't have data - certainly not Linked Data - to populate that concept.)

[RGShepherd]

Switched over in context, but not in place ... 😉

[richardofsussex]

Just needed re-generating: now done.

[RGShepherd]

Thanks! Then again, if @jpadfield's happy with http://richardofsussex.me.uk/ng/ciim7-output/place-39582.json, I think we're done.

[jpadfield]

The structure seems to work well:

flowchart TB
classDef object stroke:#2C5D98,fill:#2C5D98,color:white,rx:5px,ry:5px;
classDef url stroke:#2C5D98,fill:white,color:#2C5D98,rx:5px,ry:5px;
classDef name stroke:#563800,fill:#FEF3BA,color:#563800,rx:20px,ry:20px;
classDef place_bn stroke:#9D390F,fill:#eecaba,color:#9D390F,rx:20px,ry:20px;
classDef classstyle stroke:black,fill:white,color:black,rx:5px,ry:5px;
classDef dims stroke:#9A6D3B,fill:#9A6D3B,color:white,rx:5px,ry:5px;

O0("This Model")
class O0 object;

O1("https://gbv.github.io/jskos/context.json")
class O1 url;
click O1 "https://gbv.github.io/jskos/context.json"
O0["This Model"] ---->|has context|O1["https://gbv.github.io/jskos/context.json"]

O2("ng:0G0S-0008-0000-0000")
class O2 object;
click O2 "https://data.ng-london.org.uk/0G0S-0008-0000-0000" "Link to: https: ..."; 

O3("Ferrara@en")
class O3 name;
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|prefLabel|O3["Ferrara@en"]

O4("ng:0FZU-0008-0000-0000")
class O4 url;
click O4 "https://data.ng-london.org.uk/0FZU-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|broader|O4["ng:0FZU-0008-0000-0000"]

O5("Italy@en")
class O5 name;
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O4["ng:0FZU-0008-0000-0000"] ---->|prefLabel|O5["Italy@en"]

O6("ng:0G1U-0008-0000-0000")
class O6 url;
click O6 "https://data.ng-london.org.uk/0G1U-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O6 "https://data.ng.ac.uk/0G1U-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|broader|O6["ng:0G1U-0008-0000-0000"]

O7("Emilia@en")
class O7 name;
click O6 "https://data.ng.ac.uk/0G1U-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O6["ng:0G1U-0008-0000-0000"] ---->|prefLabel|O7["Emilia@en"]
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O6 "https://data.ng.ac.uk/0G1U-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O6["ng:0G1U-0008-0000-0000"]
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O4["ng:0FZU-0008-0000-0000"]

O8("ng:0FRT-0008-0000-0000")
class O8 url;
click O8 "https://data.ng-london.org.uk/0FRT-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O8 "https://data.ng.ac.uk/0FRT-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O8["ng:0FRT-0008-0000-0000"]

O9("Europe@en")
class O9 name;
click O8 "https://data.ng.ac.uk/0FRT-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O8["ng:0FRT-0008-0000-0000"] ---->|prefLabel|O9["Europe@en"]

O10("ng:0G6X-0008-0000-0000")
class O10 url;
click O10 "https://data.ng-london.org.uk/0G6X-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O10 "https://data.ng.ac.uk/0G6X-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O10["ng:0G6X-0008-0000-0000"]

O11("Places@en")
class O11 name;
click O10 "https://data.ng.ac.uk/0G6X-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O10["ng:0G6X-0008-0000-0000"] ---->|prefLabel|O11["Places@en"]
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O10 "https://data.ng.ac.uk/0G6X-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|inScheme|O10["ng:0G6X-0008-0000-0000"]

O12("_#-0")
class O12 place_bn;
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|location|O12["_"]

O13("Point")
class O13 classstyle;
O12["_"] ---->|type|O13["Point"]

O14("11.6167")
class O14 dims;
O12["_"] ---->|coordinates|O14["11.6167"]

O15("44.8333")
class O15 dims;
O12["_"] ---->|coordinates|O15["44.8333"]
;

[jpadfield]

Comparing it to the Linked.Art structure for "place" it might be worth considering a Linked.Art format as well?? When searching or using place names as concepts this does work well, but when we want to directly integrate places and objects etc. the addition of LA representation could make live easier.

The semantics are a little off in relation to "broader" terms but they could be useful.

In relation the concepts as well how many broader or ancestor terms are to be included, up to three levels or potentially more.

We may want to re-visit/double check this when it comes to the practical implementation of searching.

[jpadfield]

Would it be useful/realistic to add in the additional broader term relationships between the additional terms added?

flowchart TB
classDef object stroke:#2C5D98,fill:#2C5D98,color:white,rx:5px,ry:5px;
classDef url stroke:#2C5D98,fill:white,color:#2C5D98,rx:5px,ry:5px;
classDef name stroke:#563800,fill:#FEF3BA,color:#563800,rx:20px,ry:20px;
classDef place_bn stroke:#9D390F,fill:#eecaba,color:#9D390F,rx:20px,ry:20px;
classDef classstyle stroke:black,fill:white,color:black,rx:5px,ry:5px;
classDef dims stroke:#9A6D3B,fill:#9A6D3B,color:white,rx:5px,ry:5px;

O0("This Model")
class O0 object;

O1("https://gbv.github.io/jskos/context.json")
class O1 url;
click O1 "https://gbv.github.io/jskos/context.json"
O0["This Model"] ---->|has context|O1["https://gbv.github.io/jskos/context.json"]

O2("ng:0G0S-0008-0000-0000")
class O2 object;
click O2 "https://data.ng-london.org.uk/0G0S-0008-0000-0000" "Link to: https: ..."; 

O3("Ferrara@en")
class O3 name;
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|prefLabel|O3["Ferrara@en"]

O4("ng:0FZU-0008-0000-0000")
class O4 url;
click O4 "https://data.ng-london.org.uk/0FZU-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|broader|O4["ng:0FZU-0008-0000-0000"]

O5("Italy@en")
class O5 name;
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O4["ng:0FZU-0008-0000-0000"] ---->|prefLabel|O5["Italy@en"]

O6("ng:0G1U-0008-0000-0000")
class O6 url;
click O6 "https://data.ng-london.org.uk/0G1U-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O6 "https://data.ng.ac.uk/0G1U-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|broader|O6["ng:0G1U-0008-0000-0000"]

O7("Emilia@en")
class O7 name;
click O6 "https://data.ng.ac.uk/0G1U-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O6["ng:0G1U-0008-0000-0000"] ---->|prefLabel|O7["Emilia@en"]
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O6 "https://data.ng.ac.uk/0G1U-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O6["ng:0G1U-0008-0000-0000"]
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O4["ng:0FZU-0008-0000-0000"]

O8("ng:0FRT-0008-0000-0000")
class O8 url;
click O8 "https://data.ng-london.org.uk/0FRT-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O8 "https://data.ng.ac.uk/0FRT-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O8["ng:0FRT-0008-0000-0000"]

O9("Europe@en")
class O9 name;
click O8 "https://data.ng.ac.uk/0FRT-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O8["ng:0FRT-0008-0000-0000"] ---->|prefLabel|O9["Europe@en"]

O10("ng:0G6X-0008-0000-0000")
class O10 url;
click O10 "https://data.ng-london.org.uk/0G6X-0008-0000-0000" "Link to: https: ..."; 
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O10 "https://data.ng.ac.uk/0G6X-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|ancestors|O10["ng:0G6X-0008-0000-0000"]

O11("Places@en")
class O11 name;
click O10 "https://data.ng.ac.uk/0G6X-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O10["ng:0G6X-0008-0000-0000"] ---->|prefLabel|O11["Places@en"]
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O10 "https://data.ng.ac.uk/0G6X-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|inScheme|O10["ng:0G6X-0008-0000-0000"]

O12("_#-0")
class O12 place_bn;
click O2 "https://data.ng.ac.uk/0G0S-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["ng:0G0S-0008-0000-0000"] ---->|location|O12["_"]

O13("Point")
class O13 classstyle;
O12["_"] ---->|type|O13["Point"]

O14("11.6167")
class O14 dims;
O12["_"] ---->|coordinates|O14["11.6167"]

O15("44.8333")
class O15 dims;
O12["_"] ---->|coordinates|O15["44.8333"]
click O6 "https://data.ng.ac.uk/0G1U-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O6["ng:0G1U-0008-0000-0000"] ---->|broader|O4["ng:0FZU-0008-0000-0000"]
click O4 "https://data.ng.ac.uk/0FZU-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
click O8 "https://data.ng.ac.uk/0FRT-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O4["ng:0FZU-0008-0000-0000"] ---->|broader|O8["ng:0FRT-0008-0000-0000"]
;

[jpadfield]

We have broader for Italy but not Europe - is that deliberate?

Also, in relation to places and concepts how do we include external links .... AAT, Wikidata, etc .... ?

[richardofsussex]

JSKOS (https://gbv.github.io/jskos/jskos.html) has the vague related property (= RT), and the more precise idea of Concept Mappings (section 3.9). The latter is designed for external links; the former more for internal cross-referencing.

I can certainly have a go at a Linked Art mapping for places if you want one.

[jpadfield]

JSKOS (https://gbv.github.io/jskos/jskos.html) has the vague related property (= RT), and the more precise idea of Concept Mappings (section 3.9). The latter is designed for external links; the former more for internal cross-referencing.

I can certainly have a go at a Linked Art mapping for places if you want one.

I think it could be a good, but it may well need to be a for later idea ... see what @RGShepherd thinks about timings etc.

[RGShepherd]

The semantics are a little off in relation to "broader" terms but they could be useful.

No, they're a correct reflection of the source data, which is polyhierarchical. We've placed Italian cities as children of both Italy and the relevant region, as an aid to facetting and discovery.

We have broader for Italy but not Europe - is that deliberate?

Yes, our top-level terms for places are continents.

In relation the concepts as well how many broader or ancestor terms are to be included, up to three levels or potentially more.

Broader terms are always one level, ancestors as many as required.

Would it be useful/realistic to add in the additional broader term relationships between the additional terms added?

I suspect it would over-complicate the model, and I believe our mapping is JSKOS-compliant.

Also, in relation to places and concepts how do we include external links .... AAT, Wikidata, etc .... ? JSKOS (https://gbv.github.io/jskos/jskos.html) has the vague related property (= RT), and the more precise idea of Concept Mappings (section 3.9). The latter is designed for external links; the former more for internal cross-referencing.

Then @richardofsussex , please could you add concept link blocks as required?

I can certainly have a go at a Linked Art mapping for places if you want one.

Not now, thank you - we agreed to continue working with JSKOS: https://github.com/national-gallery/NG-CIIM/issues/17#issuecomment-1516603412

[jpadfield]

We have broader for Italy but not Europe - is that deliberate?

Yes, our top-level terms for places are continents.

Ok, its a top level term, sorry why does that mean we do not have broader?

In relation the concepts as well how many broader or ancestor terms are to be included, up to three levels or potentially more.

Broader terms are always one level, ancestors as many as required.

So, just checking so the source data is always pre-filled with all of the broader terms except the top-level term, for places and concepts and the number of terms to be included is only fixed by the polyhierarchical vocabulary.

Would it be useful/realistic to add in the additional broader term relationships between the additional terms added?

I suspect it would over-complicate the model, and I believe our mapping is JSKOS-compliant.

Ok

Not now, thank you - we agreed to continue working with JSKOS: #17 (comment)

Understood that this is what was noted before, but I just wanted to flag that when we finally publish NG data as Linked.Art we may also want a LA model for places - this will be very much based on how people want to use our data and how they might want to use LA data. There are only so many hours in the day though, so happy to put this in the things we might do next pile.

[richardofsussex]

Also, in relation to places and concepts how do we include external links .... AAT, Wikidata, etc .... ?

JSKOS (https://gbv.github.io/jskos/jskos.html) has the vague related property (= RT), and the more precise idea of Concept Mappings (section 3.9). The latter is designed for external links; the former more for internal cross-referencing.

Then @richardofsussex , please could you add concept link blocks as required?

Neither the place example nor the concept one have any equivalence links to external authorities. Can I take the agent examples as a guide to the input structure to be mapped, e.g. https://data.ng.ac.uk/es/public/_search?q=@admin.id:agent-7983 ? We will also, at some point, need data to test/prove the mapping.

[RGShepherd]

We have broader for Italy but not Europe - is that deliberate?

Yes, our top-level terms for places are continents.

Ok, its a top level term, sorry why does that mean we do not have broader?

Sorry, misunderstood the question; but the answer is as for the following question: broader terms are the parents only of the term in question; Europe is a (great-)grandparent.

In relation the concepts as well how many broader or ancestor terms are to be included, up to three levels or potentially more.

Broader terms are always one level, ancestors as many as required.

So, just checking so the source data is always pre-filled with all of the broader terms except the top-level term, for places and concepts and the number of terms to be included is only fixed by the polyhierarchical vocabulary.

The source data is contained in @hierarchy, which contains all ancestors in each hierarchy, one array per hierarchy if the entry is polyhierarchical. In this case, therefore, there are two arrays, because there are two hieararchies. These include all ancestors up to and including the top-level entry, and indeed the concept scheme as well. On mapping to JSKOS, we:

• include one parent per hierarchy in broader
• include all ancestors, including the top-level entry and concept scheme name, for each hierarchy in ancestors
• include the concept scheme name in inScheme

We believe this is JSKOS compliant. Is there anything about it that makes you think it isn't?

[RGShepherd]

Neither the place example nor the concept one have any equivalence links to external authorities. Can I take the agent examples as a guide to the input structure to be mapped, e.g. https://data.ng.ac.uk/es/public/_search?q=@admin.id:agent-7983 ? We will also, at some point, need data to test/prove the mapping.

Yes, please do. In the meantime, I'll try and add some proof-of-concept external links to our sample place and concept records.

[RGShepherd]

I've just kicked off a CIIM extraction which should add some external IDs to place-39582.

[richardofsussex]

Looking into this, I see that JSKOS has a baroque Concept Mappings framework: https://gbv.github.io/jskos/jskos.html#concept-mappings (with an example or two right at the end of the page). This is not a feature that is shared by SKOS. My instinct is to ignore this 'opportunity', and instead to add a simple 'exactMatch' property to the context document (which means we would have to create our own), and express these equivalences in much the same way as we express broader/narrower concepts. What do you think?

[richardofsussex]

In other words:

[RGShepherd]

I hate to say it, but I think that, if we're implementing JSKOS, we should follow their defined method of making this assertion and use their 'concept mappings' as defined. But we would only need to use type, from and to, I think.

[RGShepherd]

In other words, as per https://github.com/national-gallery/NG-CIIM/issues/21#issuecomment-1747312671 which relates to http://richardofsussex.me.uk/ng/ciim7-output/concept-41477.json

[RGShepherd]

Hmm. Should our record actually be an array, or just a single record with one each of the following child blocks?

• @context
• uri
• prefLabel
• broader
• ancestors
• inScheme
• location
• mappings [comprising:]
  • type
  • from
  • to

That seems more logical to me, and I believes reflects https://gbv.github.io/jskos/jskos.html#concept, but I admit the online examples are not clear because they do not show a mapping in the context of a larger record. :facepalm:

[richardofsussex]

Initially I tried putting the mappings there, but since that block has no key, the only place it legally can go is within an array. (I was also having to guess where it should go, without a complete example to guide me.)

[RGShepherd]

I think it should have a key, according to https://gbv.github.io/jskos/jskos.html#concept, it's just that none of the examples use it? But it's not in the @context, https://gbv.github.io/jskos/context.json, which strikes me as a bug in JSKOS. If you agree, should we raise an issue on https://github.com/gbv/jskos/issues ?

[richardofsussex]

OK, I've just done that. It will be interesting to see what comes back (and when).

[RGShepherd]

https://github.com/gbv/jskos/issues/119 😉

[richardofsussex]

https://github.com/gbv/jskos/issues/119 now has some useful answers and suggestions. I'm tempted to simply copy the approach in his last suggestion in full: what do others think?

[RGShepherd]

AFAICT, that seems sensible. But I'm not sure it tells us yet how that mappings block sits in the JSKOS JSON document for any given concept?

[richardofsussex]

I think Jakob's example does that. It's a complete JSKOS JSON document, with the uri and prefLabel defined for Ferrara. So the mappings array just sits at the top level, alongside the custom _exactMatch block which gives us SKOS-compatibility. Mappings itself doesn't appear in the @context document because it is a native JSKOS key which has no equivalent in SKOS. (The purpose of @context is to map across to a suitable RDF representation, just as the Linked Art one maps to CIDOC CRM RDF. If there's nothing to map to in the target framework, that key is simply not mapped, and so doesn't need to appear in @context.)

[RGShepherd]

Got it! And yes, I see mappings now - I was a bit snow blind. So if you're happy, I'd say go for it.

[richardofsussex]

I think http://richardofsussex.me.uk/ng/ciim7-output/place-39582.json is about right.

[RGShepherd]

That looks OK to me - thanks! Shall we take this as closed? And if we extend this to https://github.com/national-gallery/NG-CIIM/issues/21, as discussed, then I think we'll be in a position to close that one, too.

[RGShepherd]

Noting here the Linked Places Format, https://github.com/LinkedPasts/linked-places-format, which seems to have emerged from Pelagios. Not sure we want to consider switching over to it, but thought it worth noting.