English labels not shown for classification, funder type and stock size

[acka47]

We have labels for them in English but they are not used when "English is chosen as language. Look at https://github.com/hbz/lobid-organisations/issues/223#issue-164098355 for an example.

[fsteeg]

You mean we have them in the SKOS data, right? Here:

https://github.com/lobid/vocabs/blob/master/fundertype.ttl https://github.com/lobid/vocabs/blob/master/libtype.ttl https://github.com/lobid/vocabs/blob/master/stocksize.ttl

They are not part of the organisations data yet. I'd suggest a format like what we did for the name, so current data like this:

"classification": {
    "id": "http://purl.org/lobid/libtype#n81",
    "label": "Wissenschaftliche Spezialbibliothek"
}

Would become:

"classification": {
    "id": "http://purl.org/lobid/libtype#n81",
    "label": "Wissenschaftliche Spezialbibliothek",
    "label_en": "Academic Special Library"
}

I will have to manually duplicate the SKOS data in the morph to use it in the transformation.

If we'd store the classification data as simple two-value CSV files (one for each language) instead of TTLs, we could use it directly in the morph and have only one version, which we could maintain on GitHub, and which would automatically be used in the transformation.

We briefly touched this topic before, starting at https://github.com/hbz/lobid-organisations/issues/116#issuecomment-196366431.

[acka47]

If we'd store the classification data as simple two-value CSV files (one for each language) instead of TTLs, we could use it directly in the morph and have only one version, which we could maintain on GitHub, and which would automatically be used in the transformation.

What about JSON-LD? For OER Worldmap we use JSON-LD for controlled vocabularies and it can be directly used in the appplication...

[fsteeg]

I'm not aware of a way that JSON would be directly supported in the Metafacture morph file.

[acka47]

What about converting the ttl to JSON-LD as we do in lobid-resources and converting the result to csv as we do for hbz/lobid-organisations#47? We would then only have one version and the csv could be updated automatically whenever the ttl changes.

[fsteeg]

Should be possible, but seems like a very complex process for ending up with simple key-value pairs. If there is a reason for the TTL files this might be a viable solution. If the TTLs are not use elsewhere, I think we should just maintain the data in the format we need it in.

[acka47]

As it is a SKOS vocabulary with URIs for concepts (that we use in our data) we should continue publishing it as such under the vocabulary URI. (I didn't find any third-party usage of the data except https://github.com/gbv/jskos-data.) There are three options:

1. The turtle vocabulary is the authoritative version and we automatically update the CSV needed for lobid when the turtle changes.
2. The turtle vocabulary is the authoritative version and we manually update the CSV needed for lobid when the turtle changes (current approach).
3. Publish the vocab as tabular data using the Metadata Vocabulary for Tabular Data which enables converting it to RDF (automatically?)

As the data doesn't change too often, we might continue with 2. I can add the English labels to the tabular file, just tell me how...

[fsteeg]

In the current approach, the data is duplicated in the morph itself, starting at: https://github.com/hbz/lobid-organisations/blob/master/app/transformation/morph-enriched.xml#L369

The CSV would be an option, since it can be referenced directly in the morph, like we do starting here: https://github.com/hbz/lobid-organisations/blob/master/app/transformation/morph-enriched.xml#L361

So if we just add the english data with our current approach, we could add it to the embedded maps.

[fsteeg]

Deployed to staging, see:

http://test.lobid.org/organisations/search?q=bonn http://test.lobid.org/organisations/DE-B2042 http://test.lobid.org/organisations/DE-B2042?format=json

[acka47]

+1 What's still missing to make it fully localized is a German translation for "type".