Agreement on what LPF is

[rybesh]

Before we get into the weeds of discussing various proposals for new properties of LPF, I think there is a need for consensus on the high-level vision for the format. My understanding (which no one else may share!) is that LPF is:

1. A core “shape” (set of required attributes and their cardinalities and expected value types) for exchanging gazetteer data among applications. In particular, it is useful to have such a shape for creating visualizations and for indexing data from a number of sources. Anything not part of this core will be ignored by LPF-supporting tools, thus it is not really necessary to have “optional” elements of the shape—specific applications can and will layer whatever they need on top of the core.
2. LPF is GeoJSON. Thus there is an expectation that it will work normally with any tool that supports GeoJSON, even if that tool is completely unaware of LPF. Ideally LPF would “degrade gracefully” meaning that e.g. a tool for visualizing GeoJSON would still show a useful view of an LPF file even if most of the semantics in the LPF file were ignored.
3. LPF is JSON-LD, and therefore RDF. Thus there is an expectation that it will work normally with RDF tools, and that it has no semantics defined outside of RDF. In particular, this means that the core “shape” needs to be defined with SHACL or ShEx. Serialization-specific schemas will also be useful, but these should be derivative from the non-serialization-specific RDF shape.

[docuracy]

Thanks, Ryan - I think your understanding, succinctly and elegantly explained above, is probably shared by most of the members of this group.

I don't want my suggestions to be seen as an attempt to hijack LPF, to appropriate it for unintended purposes, but rather to demonstrate that by avoiding certain proscriptive and prescriptive specifications, the format could at least serve as a basis for some other data format that is not focused solely on the exchange of gazetteer data. I've arrived at this point through experimentation with various formats to try to link and represent diverse geospatial datasets, most recently in connection with the British Library's Locating a National Collection project, which is now developing the next generation of Peripleo. I've also led a project that relied heavily on Recogito, annotating historical maps, texts, and illustrations, which is currently frustrated by the absence of a sufficiently-accommodating data model.

The bottom line is that for the BL project we need to standardise within the next few months a data model that can accommodate all of the various facets of our datasets. It is tailored in tandem with and for visualisation in Peripleo, and thus likely to be adopted by others, and it will look very much like the model I have outlined in the JSON Schemas here and here. It could be any of the following:

1. A new JSON-LD.GeoJSON format (independent of LPF), or
2. An extension of LPF (requiring some flexibility in the LPF specification), or
3. LPF 2.0 (requiring adoption of new properties and a radical shift in its raison d'être).

I'm not a fan of format proliferation so would prefer option 3, but I'm also sensitive to the rightful proprietorship of Karl and others of you who have pioneered LPF.

[thegsi]

Thanks for these very considered and helpful comments. I must admit that I am not familiar with SHACL or ShEx and it would be great to discuss these in an upcoming meeting.

We have found the Linked Traces/Linked Places approach to be deficient in several respects in working with cultural heritage datasets. In particular we have found that for many records, gazetteer alignment has been problematic, particularly when referring to precise locations like findspots of archaeological objects or presenting cultural heritage objects at a local scale such as that of a neighbourhood.

We are therefore interested in discussing the inclusion of data relating to individual records within the LPF along the lines that Stephen has outlined above. Ryan, this might not be completely aligned with your first point, that LPF is for ‘exchanging gazetteer data among applications’ but it would be great to explore this next week.

[kgeographer]

My 2 cents: Ryans three points above express exactly the shared conception of LP format arrived at during its creation...by me, Rainer Simon, Richard Light, and Graham Klyne principally. To my mind, point 2 addresses many of the issues that will arise for particular applications, e.g. LNC. But since I'm not aware of all of those, I look forward to hearing the ins and outs.