Suggestion: 2 additional relation types

[gklyne]

I've just been in conversation with a colleague, and we are looking at LPiF exchange compatibility for our related work. One thing we want to do is record related places that fall outside the administrative hierarchy that I understand is the focus of this LPiF/linked pasts effort [1].

[1] https://github.com/LinkedPasts/lp-network/issues/2#issuecomment-389255487

E.g. we'd like to do things like describing a building that falls within a town - we don't expect these to be commonly present in gazetteers, but would look for some commonality of data model, and I would anticipate a successful interchange standard wouldn't be limited to gazetteers.

Currently the proposed relationships include:

"relations": [
  {"exactMatch": "" },
  {"closeMatch": "" },
  {"primaryTopicOf": "" },
  {"subjectOf": "" },
  {"seeAlso": "" },
]

"exactMatch" and "closeMatch" look as if they might be SKOS-inspired. I was wondering if there's a case for also allowing "broader" and "narrower"; these might also be more generally useful for the stated purpose of relations being "the central means of linking places and gazetteer datasets".

Or is it intended that the allowed set of relations is open-ended? (Though that might militate against effectiveness as an interchange standard.)

[renevoorburg]

Broader and narrower in SKOS stand for broader or more specific subjects. In a sense, those are partOf / hasPart relations. I guess the 'parthood' is to be used for that?

[rsimon]

In Pelagios we use skos:broadMatch as a means to point to broader concepts in other gazetteers. (E.g. to say that a specific place/neighborhood/etc. in my gazetteer belongs to the larger place/region in Pleiades, GeoNames, etc.) I know that’s quite a bit of semantic overloading, as it were. But perhaps still something to keep in mind as a use case.

(FWIW in the initial ‚relations‘ property in the LPIF could have been defined as „links pointing to entities in other datasets“, which might have resolved this issue? However due to the fact that we need the skos predicates to attach to the Place (rather than the relations object) we probably have to let go of this construct?)

[gklyne]

@renevoorburg My comment was, in part, responding to "The partOf relation, in PGIFv1 and going forward to v2 is not spatial" [1]

[1] LinkedPasts/lp-network#2 (comment)

This suggests to me that we'd need something else for spatial containment, such as a building in a populated place. Hence the suggestion for something not "PartOf".

@rsimon Ack. re "other gazetteers", though I'd aim to employ a data model that isn't too sensitive to where the data is actually stored. I suggested SKOS properties more as indicative of intended semantics rather than as specific vocabulary; it's not entirely clear to me from the documents I'm seeing how the related and relations terms are intended to be used here, so it's hard for me to make a more specific observation.

Generally, I raised the issue to see if this is something you wanted to capture in PGIFv2 - I have no particular axe to grind here - if it's not considered to be interesting for PGIF/LPIF purposes, then fine. I think PGIF, as targeted ("Our goal is not to define The One unified data model to represent gazetteers"), will necessarily lose some fidelity of the systems between which it is used - I guess the question becomes: how much fidelity is it OK to lose?