update destatis

[maipet]

Related to #41

[maipet]

@acka47 as discussed, the language labels for "en" and "uk" from the current hfs have been added and the duplicate notation "10" deleted

[acka47]

Das sieht super aus. Und da die Label jetzt je eine eigene Zeile haben, werden die zukünftigen Diffs noch sprechender sein, oder sehe ich da was falsch. So können wir das auf jeden Fall beim nächsten Treffen zum Mergen vorschlagen.

Allerdings gibt es noch ein Problem mit dem SkoHub Build, das ich nicht verstehe, siehe https://skohub.io/build/?id=6f2d0537-c96b-43c3-b7e9-fda8a8a8fb20

(Ich hatte den Build auch ein zweites Mal angestoßen, und es kam die gleiche Meldung.)

[acka47]

Ah, das Problem ist glaube ich, dass die @baseURI fehlt.

[acka47]

Ja, die fehlende @base-URI war das Problem und der SkoHub Build lief durch nach e8bc231, siehe https://skohub.io/dini-ag-kim/hochschulfaechersystematik/heads/41-UpdateDestatis/w3id.org/kim/hochschulfaechersystematik/scheme.html

Beim Blick auf die SkoHub-Versions sind mir noch zwei Destatis-Notationen aufgefalen, die nicht in der t Hochschulfächersystematik auftauchen sollten:

• https://skohub.io/dini-ag-kim/hochschulfaechersystematik/heads/41-UpdateDestatis/w3id.org/kim/hochschulfaechersystematik/n15.html
• https://skohub.io/dini-ag-kim/hochschulfaechersystematik/heads/41-UpdateDestatis/w3id.org/kim/hochschulfaechersystematik/n20.html

[acka47]

Hier der Beginn einer Aufzählung, was der PR alles macht (du kannst den Kommentar gerne editieren, @maipet ):

• 2 Notationen korrigieren:
  • <n0128> a skos:Concept -> <n128> a skos:Concept
  • <n030010001> a skos:Concept -> <n292> a skos:Concept
• Das Turtle besser sortieren, damit sich in Zukunft diffs besser lesen lassen:
  • Labels für verschiedene Sprachen in je eine Zeile.
  • broader- / narrower-Beziehungen in je einer Zeile
• narrower-Beziehungen entfernen, da redundant zu den inversen broader-Beziehungen, die drin bleiben. Damit wird die Pflege erleichtert.
• Ergänzung zweier Skripte, die einige dieser Arbeiten übernehmen. Sollten wir die nicht auch in der README dokumentieren?
• deprecated aus der vorherigen Version beibehalten

Beim Schreiben der Liste ist mir aufgefallen, dass die deprecated concepts aus der aktuellen Version in diesem Branch ganz verschwunden sind. Hier die entsprechenden Stellen im master Branch:

hochschulfaechersystematik/hochschulfaechersystematik.ttl

Lines 1106 to 1112 in e2b0e04

	<n241> a skos:Concept ;
	skos:prefLabel "Kerntechnik/Kernverfahrenstechnik"@de, "Nuclear technology/nuclear process engineering"@en, "Атомна інженерія/Інженерія ядерних процесів"@uk ;
	skos:broader <n63> ;
	skos:notation "241" ;
	owl:deprecated true ;
	skos:note "Integrated into 211"@en ;
	skos:inScheme <scheme> .

hochschulfaechersystematik/hochschulfaechersystematik.ttl

Lines 1639 to 1645 in e2b0e04

	<n237> a skos:Concept ;
	skos:prefLabel "Mathematische Statistik/Wahrscheinlichkeitsrechnung"@de, "Mathematical statistics/probability calculation"@en, "Математична статистика/Теорія ймовірності"@uk ;
	skos:broader <n37> ;
	skos:notation "237" ;
	owl:deprecated true ;
	dct:isReplacedBy <n312> ;
	skos:inScheme <scheme> .

Die müssen ja – als deprecated markiert – drinbleiben.

[maipet]

Ich hab nun doch noch die narrower relations ergänzt, da so ggf. gezielte Abfragen ermöglicht werden.
Ich bin nicht sicher, ob die Verlinkung auch zu den deprecated concept gesetzt werden soll? Gelten diese noch als narrower? Im Moment habe ich diese Beziehung nicht gesetzt, soll ich es ergänzen?

[acka47]

Ich hab nun doch noch die narrower relations ergänzt, da so ggf. gezielte Abfragen ermöglicht werden.

Ok, wenn wir das ohnehin automatisch generieren, passieren ja auch keine Fehler und es macht keine Probleme bei der Pflege.

Ich bin nicht sicher, ob die Verlinkung auch zu den deprecated concept gesetzt werden soll? Gelten diese noch als narrower? Im Moment habe ich diese Beziehung nicht gesetzt, soll ich es ergänzen?

Es hat sich in der Vergangenheit gezeigt, dass die deprecated concepts weiterhin in der Hierarchie eingehänt sein sollten, siehe #35 (comment). Wir haben das dementsprechend auch in der StöberSpecs-Doku festgehalten (siehe dini-ag-kim/stoeberspecs#12), wo es jetzt heißt:

Veraltete SKOS-Konzepte werden als solche mit owl:deprecated true markiert und – so vorhanden – mit dct:isReplacedBy auf das Nachfolge-Konzept verlinkt. skos:broader- oder skos:narrower-Relationen der veralteten Konzepte sollen aber unangetastet bleiben.

[acka47]

+1

[oellers]

I'd suggest to eliminate the build warnings, e.g. by adding dct:license and dct:source.

Suggestion:

• dct:license
  Find/Use an appropriate license URI, e.g. from DCT AP?
  http://dcat-ap.de/def/licenses/other-closed

• dct:source
  The URI to the source
  https://www.destatis.de/DE/Methoden/Klassifikationen/Bildung/studenten-pruefungsstatistik.html

[mic-men]

Ich habe alles einmal durchgesehen hinsichtlich Logik und Tippfehler. Sieht für mich alles gut aus.
Allerdings hadere ich noch mit den Korrekturen bzgl. IDs n0128 und n030010001. Sachlich richtig, aber unsere eingesetzte Software berücksichtigt deprecated und replacedBy (bisher) nicht und es wird zu Problemen kommen. Ich möchte daher nochmal zur Diskussion stellen, ob wir die fehlerhaften IDs nicht doch (noch) beibehalten sollen?
Es ist ein Unterschied in der Praxis, ob ein eher nebensächliches Fach deprecated ist und irgendwo aufgeht oder ob ein essentielles Fach wie Physik eine andere ID bekommt.

[acka47]

Allerdings hadere ich noch mit den Korrekturen bzgl. IDs n0128 und n030010001. Sachlich richtig, aber unsere eingesetzte Software berücksichtigt deprecated und replacedBy (bisher) nicht und es wird zu Problemen kommen. Ich möchte daher nochmal zur Diskussion stellen, ob wir die fehlerhaften IDs nicht doch (noch) beibehalten sollen?
Es ist ein Unterschied in der Praxis, ob ein eher nebensächliches Fach deprecated ist und irgendwo aufgeht oder ob ein essentielles Fach wie Physik eine andere ID bekommt.

Ich sehe das genauso. Vorschlag: Wir passen zumindest einmal n030010001 an zu n292, weil das ja komplett daneben ist und dazu wahrscheinlich noch von niemandem benutzt wurde. n0128/Physik lassen wir hingegen wie es ist. Was meinst du?

[mic-men]

Ich sehe das genauso. Vorschlag: Wir passen zumindest einmal n030010001 an zu n292, weil das ja komplett daneben ist und dazu wahrscheinlich noch von niemandem benutzt wurde. n0128/Physik lassen wir hingegen wie es ist.

Ja, dem kann ich zustimmen. Tatsächlich haben wir das Fachgebiet von n292 bei uns bereits benutzt, aber das können wir mit überschaubarem Aufwand manuell nachpflegen.

[acka47]

Sieht gut aus, auch im SkoHub build dieses Branches:

• 128 Physik
• 292 Islamische Studien/Islamische Theologie

[acka47]

+1

[mic-men]

Die ID-Änderung wie besprochen ist in Ordnung. Zu den Py-Skripten kann ich kein kompetentes Feedback geben.