Minor: adjustment to Original Label/Alternate Label

[atomrab]

Entering Chinese periods where the original label is in Chinese script, it occurred to me that we should a) find a better way to let the user see the English label for non-English items (right now you have to open the edit window); and b) clarify the "alternate label" field, which doesn't distinguish between the primary English translation and any other kind of alternate label. We should make sure that there's a primary English version that can be accessed easily by the user wherever possible -- right now, a non-Chinese-speaking user won't be able to figure out Chinese periods.

[ptgolden]

a) find a better way to let the user see the English label for non-English items (right now you have to open the edit window)

This is already done in the newest version (not yet released, I will let you know when it is).

b) clarify the "alternate label" field, which doesn't distinguish between the primary English translation and any other kind of alternate label.

Does the source include an English translation? I was under the impression that alternate labels were alternate labels that were indicated within the source material. We have no way of differentiating between a) alternate labels for a period defined within a source, and b) alternate labels added by the "curator" publishing assertions to PeriodO.

If we want to clearly delineate those two types of "alternate labels", we will need to either change the data model, or do something fancy with indicating provenance.

[atomrab]

So we have two scenarios, one in which the source does include an English translation (ARIADNE, CHGIS), and one in which it does not, but the input person provided one (the Historiska and Dutch periodizations, which I added myself). I tend to think it would be good to strongly recommend than a user input English translations whenever possible, but you're right that we should distinguish these somehow.

In our original data model, I thought that the English label was assumed to be produced by the curator, even if it was more or less in the original datasource (thus we copied over period names from label_original to label_en, often removing, as I did with the BM values, the word "period" as redundant). But that wasn't always true -- we used the Fasti translations, for example. So this is definitely an issue we should address.

I am drawn toward "something fancy with provenance", which we might be able to adapt to other use-cases, but I understand if this is high-effort and low sustainability. Ryan and Eric, thoughts?

[rybesh]

In the current data model:

• skos:prefLabel is used for the name of the period exactly as given in the original source. The value of this property is a simple literal xsd:string, with no language tag.

• skos:altLabel is used for language-specific names of the period, assigned by PeriodO curators. The value of this property is a language-tagged string. The language tag consists of (at least)

  1. a three-character primary language subtag, as defined in ISO 639-2 or ISO 639-3, and
  2. a four-character script subtag, as defined in ISO 15924.

  There will always be at least one skos:altLabel, with the language tag eng-latn. If the source definition was not written in English, there will always be another skos:altLabel with a language tag indicating the language and script of the source definition.

I'm not convinced that we need to get into tracking provenance of labels, or treating more than one label as "original."

[atomrab]

Sorry to reopen, but does this mean we need to go through and add a second altlabel with a language code for all the non-English entries? We didn't have this set up in the original spreadsheet, so all the language and script coding we had there must have been stripped (I assume -- looks like the JSON-LD/RDF view isn't available in the current version, so I can't tell if it's in the JSON-LD).

[ptgolden]

I think this is the same thing we discussed in #56. Nothing has been stripped- it was missing from the visible interface. That is no longer the case with 4ca7772.