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

Discussion: Core data #26

Open
kintopp opened this issue Aug 3, 2018 · 2 comments
Open

Discussion: Core data #26

kintopp opened this issue Aug 3, 2018 · 2 comments
Assignees

Comments

@kintopp
Copy link
Member

kintopp commented Aug 3, 2018

Please respond in this thread to the planned amendments to our 'core data' definition described in Graham's note:

https://github.com/culturesofknowledge/emplaces/blob/develop/models/20180802-multisource-data-model-notes.md

@kintopp
Copy link
Member Author

kintopp commented Aug 3, 2018

Graham has prepared a revised version of the Opole example data on his development branch:

https://github.com/culturesofknowledge/emplaces/blob/develop/models/20180802-opole-example-multisourced.ttl

For comparison, see the previous version: https://github.com/culturesofknowledge/emplaces/blob/master/models/20180410-opole-example-data.ttl

@gklyne
Copy link
Contributor

gklyne commented Aug 3, 2018

Reviewing this, I've noticed a semantic subtlety that I've overlooked. I don't think it has practical consequences at this time, but i think it's important to maintain clarity about the semantics.

Originally, an em:Place instance could be interpreted as denoting the place itself, or as denoting information about the place, where the interpretation chosen didn't really have any impact. With the introduction of multiple instances corresponding to different sources of information, they are clearly denoting information about the place (otherwise the em:source properties would be meaningless). Welcome to HTTP-Range-14 territory :).

This leads me to conclude that if all our place nodes are information resources about some place (which I suspect was always the case), we maybe should also consider acknowledging use of something like a foaf:primaryTopic to that the place itself can have a denotation in EMPlaces data.

As I say above, I don't think this has any immediate practical consequences, since we're anyway working pretty much entirely with information about places - but I can imagine future situations where the distinction might have some impact, hence a desire for clarity now.

I'm working on some minor revisions to the data that reflect this interpretation (mainly involving labels and descriptions, but also clarifying some subclass relations), which may in turn affect line number references into the example data files.

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

2 participants