New exported format: Simple Knowledge Organization System (SKOS) (Basic implementation or better); RDF on Turtle

[fititnt]

• The standard:
  • https://www.w3.org/2004/02/skos/
  • https://www.w3.org/TR/skos-reference/
  • https://www.w3.org/TR/skos-primer/
  • https://www.w3.org/TR/skos-ucr/
• Software (incomplete list)
  • https://www.skosmos.org/
    • https://github.com/NatLibFi/Skosmos
  • https://vocabularyserver.com/web/
    • https://github.com/tematres/TemaTres-Vocabulary-Server
  • https://iqvoc.net/
    • https://github.com/innoq/iqvoc
  • https://blog.skohub.io/2020-03-31-skohub-editor/
  • https://github.com/skohub-io/skohub-editor
• Real world examples (incomplete list)
  • https://eur-lex.europa.eu/browse/eurovoc.html?locale=pt
    • https://op.europa.eu/pt/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/eurovoc
• https://vocabularies.unesco.org/browser/thesaurus/en/
  • https://vocabularies.unesco.org/exports/thesaurus/latest/unesco-thesaurus.ttl
• https://www.fao.org/agrovoc/linked-data
  • This page have list to several other ontologies!
• Online visualization/syntax validation/content validation
  • https://www.w3.org/2015/03/ShExValidata/
    • W3C official validation
  • https://skos-play.sparna.fr/play/
    • Online visualization / conversor
  • https://skos-play.sparna.fr/skos-testing-tool
    • Quite advanced!

---

Simple Knowledge Organization System (SKOS) is a W3C recommendation designed for representation of thesauri, classification schemes, taxonomies, subject-heading systems, or any other type of structured controlled vocabulary. SKOS is part of the Semantic Web family of standards built upon RDF and RDFS, and its main objective is to enable easy publication and use of such vocabularies as linked data. -- via https://en.wikipedia.org/wiki/Simple_Knowledge_Organization_System

Based on suggestion in https://dadosabertos.social/t/metadados-legislativos-e-semantica/390/3?u=rocha by @augusto-herrmann, let's add SKOS as additional exportable format.

Notes

Default codes used for languages, while valid, may intentionally use non-normalized BCP47

• SKOS | 5.6.5. Labeling and Language Tags
  • https://www.w3.org/TR/skos-reference/#L1629
• BCP47
  • https://www.rfc-editor.org/info/bcp47

Our language codes are BCP47 valid but not the most normalized format (which would require an IANA lookup). This is mostly because we

• use ISO 639-3, ignoring completely ISO 639-2; this practice is also used by linguists including on Glottocodes
  • Example: por instead of pt in por-Latn
  • This approach is less clear in European languages (unless is minority languages, than is very relevant) but it make easier to intentionally be friendly for languages which never got into ISO 639-1 and ISO 639-2
• Use ISO 15924 even when likely be unnecessary;
  • Example: Arab in arb-Arab, Latn in lat-Latn, ...

The SKOS do not state best practices of how to encode languages (just recommend BCP47). So by deciding this default, we can actually later also release the language tables.

---

Changes

• 2022-04-03T05:57Z : Added links to https://www.fao.org/agrovoc/linked-data, https://skos-play.sparna.fr/play/, https://www.w3.org/2015/03/ShExValidata/, https://skos-play.sparna.fr/skos-testing-tool

[fititnt]

Nice. At this point we have an exporter for rudimentar skos:Concept + skos:prefLabel (linguistic only; don't make sense abuse BCP47 like we do on tabular format to add inter-linguistic properties here, since RDF/SKOS/Turtle obviously support it).

• Impressions of using SKOS directly (vs compared to Best Practices for Multilingual Linked Open Data report)
  • https://www.w3.org/community/bpmlod/
    • http://bpmlod.github.io/report/multilingual-terminologies/index.html

One early attempt I stopped was trying to convert TBX to RDF based on bpmlod report but that generated somewhat ugly result at least for simpler cases (like at the moment we're doing). However, using SKOS and other examples as reference from what is used on the software for this type of task, the output format actually feel it could be edited by hand.

---

1603/63/101/1603_63_101.no11.skos.ttl

$ ./999999999/0/1603_1.py --methodus='status-quo' --status-quo-in-rdf-skos-turtle --codex-de 1603_63_101 > 1603/63/101/1603_63_101.no11.skos.ttl

[fititnt]

Okay, we're having an problem on how to organize the entire library.

At the moment, we're considering that each group is an entire skos:ConceptScheme, in a similar way we publish the PDF versions with grouped packages. UNESCO Therraurus use a different approach (https://vocabularies.unesco.org/exports/thesaurus/latest/unesco-thesaurus.ttl) that by the way requires another specification, as said here https://lists.w3.org/Archives/Public/public-esw-thes/2016Jan/0012.html.

Maybe the SKOS version always have 1603 as entry point?

I'm not 100% sure, we could make an early test to implicitly create the missing parents notes (up to 1603, or whatever root numbering would exist, since others could use others) and this would not break the things while likely not require something like iso-thes:superGroup