Most periods are missing spatialCoverageDescription

[ptgolden]

Out of 1791 period definitions, 1207 have a blank field for spatial coverage description. I'm pretty sure that in the vast majority of cases, these periods have one single entry in spatial coverage (as in, one country). It would probably make sense to copy the text of the country name to the description.

[atomrab]

We left this blank in two cases: when the coverage was unstated but obvious, and when the coverage asserted by the author was also one or more modern nation states (so we could just copy it directly).

I think that you're right, it's probably easiest to copy these over from spatial coverage. But we'll need to be rigorous in the future about differentiating between an explicit statement on the part of the source and an inference, however obvious.

[rybesh]

We left this blank in two cases: when the coverage was unstated but obvious, and when the coverage asserted by the author was also one or more modern nation states

Is there any way of reconstructing which of these was the case for the 1207 blanks?

[atomrab]

Sort of, by collection. All the Fasti definitions are the latter
(author-asserted), as are PAS, English Heritage, ARENA, Jamieson 2007,
Historiska, Rijksdienst, and Open Context. Pleiades, the UCLA Encyclopedia
of Egyptology and all the values that came in from GeoDia, at least where
spatial coverage label is blank, are the former (unstated but obvious).
The British Museum values, when they go in, are also the former -- where
there's no label, the coverage was obvious but not explicit.

But that doesn't go item by item. Will it be enough?

Adam

On Wed, Jul 8, 2015 at 12:33 PM, Ryan Shaw notifications@github.com wrote:

We left this blank in two cases: when the coverage was unstated but
obvious, and when the coverage asserted by the author was also one or more
modern nation states

Is there any way of reconstructing which of these was the case for the
1207 blanks?

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

[ptgolden]

OK, so:

Author asserted

• Fasti
• PAS
• English Heritage
• ARENA
• Jamieson 2007
• Historiska
• Rijksdienst
• Open Context

Unstated but obvious

• Pleiades
• UCLA Encyclopedia of Egyptology
• GeoDia (where coverage is blank)
• British Museum

The author-asserted values can be immediately copied to the spatialCoverageDescription field. Should the same be done for the unstated-but-obvious values?

More generally, should a spatial coverage description be required for each and every period? If that is the case, it will have consequences for the period form.

[rybesh]

should a spatial coverage description be required for each and every period?

I think that the "unstated but obvious" cases should remain without a spatialCoverageDescription so that we aren't putting words in the original source's mouth.

[atomrab]

For what it's worth, the entries for Pleiades and the British Museum
already have an editorial note explaining where the spatial coverage came
from. I can also easily add a note for the UEE, since there aren't many
entries and by default it's obviously referring to Egypt.

The same isn't true of the GeoDia entries, but we could add a bulk note to
all those without a description indicating that spatial coverage was
inferred during the GeoDia data entry process.

On Thu, Jul 9, 2015 at 7:42 AM, Ryan Shaw notifications@github.com wrote:

should a spatial coverage description be required for each and every
period?

I think that the "unstated but obvious" cases should remain without a
spatialCoverageDescription so that we aren't putting words in the
original source's mouth.

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

[ptgolden]

ok, I'll go ahead and copy spatial coverages over to spatialCoverageDescription for the "author asserted" cases above.

[ptgolden]

I don't see any sources that correspond to English Heritage or Open Context. Are they under different titles, or not in the current "Canonical" dataset?

[atomrab]

Sorry, should have been clearer on those. By "English Heritage", I meant the Heritage Data collection (http://n2t.net/ark:/99152/p0kh9ds), which derived the periods we recorded from the English Heritage thesaurus; and by "Open Context" I meant Anderson et al., Digital Index of North American Archaeology (DINAA) (http://n2t.net/ark:/99152/p086kj9).

[ptgolden]

The first batch of fixes is in https://test.perio.do/#/patches/https://test.perio.do/patches/6/. I'll add the other two in another patch.

[ptgolden]

Also the British Museum data can be approved at https://test.perio.do/#/patches/https://test.perio.do/patches/5/

[atomrab]

It occurs to me that there is a basic spatial assertion in one of the other unlabeled sources: the spatial element of the Cambridge Companion to the Aegean Bronze Age is "the Aegean". Should I go through and add this to all those values, or can that be done easily as a batch -- or do you guys think it's still too much a stretch in terms of authorial intent, and we should ignore it?

[ptgolden]

do you guys think it's still too much a stretch in terms of authorial intent, and we should ignore it

I think that you're the expert there. If you want me to, I'll add it in my followup patch.

[atomrab]

Let's do it. I think it's fair, based on the title of the work.

[rybesh]

@atomrab Can I conclude from this discussion that we officially do not require a value for spatialCoverageDescription? If so, I will close this bug and make this clear in the data model documentation and change policy.

[atomrab]

So this is the result of records -- like those of the British Museum, or the Egyptian Encyclopedia of Egyptology, or sources that presented maps as explanations -- from which spatial coverage was obvious (e.g. a set of periods for Japan, or that began with "Cypro-", or that were from Egypt by the source, or that were on a map with an outline of Greece) but which did not provide an explicit verbal assertion of spatial coverage. We therefore inferred the obvious, rather than have no spatial coverage at all for periods from eg an encyclopedia of Egypt. I think that in this case we can't require the label, right? I would like to get rid of the "undefined" value in the filter, though, which is really annoying. How should we handle this? Can we have a special type of spatial coverage description that is inferred from the obvious?

…

On Thu, Jan 26, 2017 at 1:42 PM, Ryan Shaw ***@***.***> wrote: @atomrab <https://github.com/atomrab> Can I conclude from this discussion that we officially do not require a value for spatialCoverageDescription? If so, I will close this bug and make this clear in the data model documentation and change policy. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEhXgy8a4uVQTfmx_1RqG6bxjPVoDcSQks5rWPctgaJpZM4FUf9F> .

[rybesh]

I was thinking that it would be fine to not require this (but we should require at least one spatial entity to be specified; see issue #34). Why is the "undefined" value in the filter annoying?

[atomrab]

I don't mean it's annoying to have it -- it's actually very useful for data cleaning, when there are no spatial characteristics at all. But it's annoying not to have a way to use location to filter entries that have a spatial coverage but not a spatial coverage description. So you pull up, say, "Archaic", but you only want to look at Greece -- if you include "undefined", you get a series of irrelevant values for Cyprus, but if you don't include it, you lose the BM definition of Archaic for Greece. What I'd really like is a way to include spatial coverage description if it's there, and substitute spatial coverage in the filter window if it's not. Then the only "undefined" values would be those that lack both.

…

On Thu, Jan 26, 2017 at 2:27 PM, Ryan Shaw ***@***.***> wrote: I was thinking that it would be fine to not require this (but we should require at least one spatial entity to be specified; see issue #34 <#34>). Why is the "undefined" value in the filter annoying? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEhXg7nvuneoIiilML-Qc7T4VfZkVoUbks5rWQGvgaJpZM4FUf9F> .

[rybesh]

This is a client issue, see periodo/periodo-client#120