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

Should spatialCoverageDescription be required? #18

Closed
ptgolden opened this issue Mar 12, 2015 · 5 comments
Closed

Should spatialCoverageDescription be required? #18

ptgolden opened this issue Mar 12, 2015 · 5 comments

Comments

@ptgolden
Copy link
Member

Some entries in the dataset do not currently have a value for spatialCoverageDescription, which (if I understand correctly) is the spatial coverage explicitly defined within the source (ie not added by the curator)

@atomrab
Copy link

atomrab commented Mar 12, 2015

We used this to describe spatial coverage that couldn't be immediately translated into a URI for a modern administrative division. If the source explicitly said "Israel" or "France" or "Sicily" or anything else resolvable against a modern gazetteer, we put that information here (like "Mesopotamia" or "Northern Etruria") to indicate that we had to do some parsing to get our spatial coverage. If it's more consistent to have this for all entries, all the blanks should just repeat the spatial coverage value.

@rybesh
Copy link
Member

rybesh commented Mar 12, 2015

Isn't it possible that the source says nothing explicit about spatial coverage but that it can be inferred (e.g. given the topic/focus of the source)? In which case it's possible that there is no spatialCoverageDescription but there are spatialCoverage entities chosen by the curator.

@atomrab
Copy link

atomrab commented Mar 12, 2015

Yes -- for instance, a book on "Iron Age France" or "the Bronze Age Aegean". This is how we did it in the spreadsheet. So I guess that undermines my statement that you can copy spatialCoverage to spatialCoverageDescription, because the author may never have explicitly said "and I'm talking about France".

@ptgolden
Copy link
Member Author

Here's my proposed answer to my provocatively-posed question, combining both of your comments

  1. A spatial coverage description should be the actual description included in the source
  2. The value of spatial coverage is a curatorially-derived group of linked data entities that have associated shapes.
  3. If the source did not include a description, but its spatial coverage is obvious, the spatial coverage description field will remain blank, but the spatial coverage will be appropriately filled

(2) applies even when (1) can be mapped to a modern administrative division. So, if the source says a time period covers "Spain", the spatial coverage will still have an entry for "Spain" in geonames (or dbpedia, or whatever).

This is similar to our approach with start/stop dates: a textual label directly from the source, and derived structured data that estimates the natural language for use in a computer interface.

@atomrab
Copy link

atomrab commented Mar 12, 2015

Yes, I think this is more or less what we've already been doing, but
without the clear and explicit rationale. Thanks!

On Thu, Mar 12, 2015 at 1:00 PM, Patrick Golden notifications@github.com
wrote:

Here's my proposed answer to my provacatively-posed question, combining
both of your comments

  1. A spatial coverage description should be the actual description
    included in the source
  2. The value of spatial coverage is a curatorially-derived group of
    linked data entities that have associated shapes.
  3. If the source did not include a description, but its spatial
    coverage is obvious, the spatial coverage description field will remain
    blank, but the spatial coverage will be appropriately filled

(2) applies even when (1) can be mapped to a modern nation state. So, if
the source says a time period covers "Spain", the spatial coverage will
still have an entry for "Spain" in geonames (or dbpedia, or whatever).

This is similar to our approach with start/stop dates: a textual label
directly from the source, and derived structured data that estimates the
natural language for use in a computer interface.


Reply to this email directly or view it on GitHub
#18 (comment).

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

No branches or pull requests

3 participants