Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support broadMatch/hierarchical gazetteers #211

Open
rsimon opened this issue Nov 23, 2017 · 1 comment
Open

Support broadMatch/hierarchical gazetteers #211

rsimon opened this issue Nov 23, 2017 · 1 comment

Comments

@rsimon
Copy link
Member

rsimon commented Nov 23, 2017

Model-wise, we can add is_part_of or skos:broadMatch relations to items, to indicate a parent-child relationship. (This is different to skos:closeMatch and skos:exactMatch as it won't lead to conflation.) But the implementation is unfinished. What we want is...

  1. Items linked to a places that has a broadMatch should show up as results to their parent match
  2. The Linked Data view should pull broadMatches out of the system and render them into the graph
  3. (Potentially) search result list and selection box should indicate the existence of a broadMatch (and show a formatted link).

Problem re 3.: how to distinguish between broadMatches that are actually resolvable in the system vs. those that aren't? Potentially, we'd need to ping this on demand from the UI. The other alternative would be to pack this into the ingest (which would make it more complex)

@rsimon
Copy link
Member Author

rsimon commented Nov 23, 2017

P.S.: gazetteers currrently making use of broadMatch are: Cyprus, Libya, DEFC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant