Community Patterns für SKOS Notes

SKOS hat verschiedene Properties zur Ergänzung von notes:

  • skos:note als generische, übergeordnete Property
  • skos:changeNote
  • skos:editorialNote
  • skos:historyNote
  • skos:scopeNote

Gibt es irgendwelche Empfehlungen, wie diese angewendet werden sollten? Zum Einen sind inhaltliche Fragen interessant (Welche Property benutze ich für welchen Use Case?) zum Anderen formale Fragen. Was die formalen Dinge angeht, haben wir im SkoHub-Kontext andiskutiert, ob nicht die Wiederholung mancher oder aller note-Felder vermieden werden sollte und besser pro language tag nur je eine note angelegt werden sollte.

Hat sich da schonmal jemand hier Gedanken drüber gemacht oder kennt entsprechende Veröffentlichungen?

1 „Gefällt mir“

Für die erste inhaltliche Frage nach der Verwendung gibt der SKOS Primer schon einiges her unter 2.4 Documentary Notes. Leider bleibt die zweite Frage unbeantwwortet. Ich zitiere das hier mal komplett:

2.4 Documentary Notes

Semantic relationships are crucial to the definition of concepts, as many KOS guidelines emphasize it. However, next to these structured characterizations, concepts sometimes have to be further defined using human-readable („informal“) documentation, such as scope notes or definitions.

SKOS provides a skos:note property for general documentation purposes. Inspired by existing KOS guidelines, such as [ISO2788] or [BS8723-2], this property is further specialized into skos:scopeNote, skos:definition, skos:example, and skos:historyNote to fit more-specific types of documentation.

skos:scopeNote supplies some, possibly partial, information about the intended meaning of a concept, especially as an indication of how the use of a concept is limited in indexing practice. The following example is adapted from [ISO2788]:

ex:microwaveFrequencies skos:scopeNote "Used for frequencies between 1GHz to 300Ghz"@en.

skos:definition supplies a complete explanation of the intended meaning of a concept. The following example is adapted from [ISO2788]:

ex:documentation skos:definition "the process of storing and retrieving information in all fields of knowledge"@en.

skos:example supplies an example of the use of a concept:

 ex:organizationsOfScienceAndCulture skos:example "academies of science, general museums, world fairs"@en.

skos:historyNote describes significant changes to the meaning or the form of a concept:
ex:childAbuse skos:historyNote „estab. 1975; heading was: Cruelty to children [1952-1975]“@en.
In addition to these notes that are intended for users of a concept scheme, SKOS includes two specializations of skos:note that are useful for KOS managers or editors: skos:editorialNote and skos:changeNote.

skos:editorialNote supplies information that is an aid to administrative housekeeping, such as reminders of editorial work still to be done, or warnings in the event that future editorial changes might be made:

ex:doubleclick skos:editorialNote "Review this term after company merger 
                             complete"@en.
ex:folksonomy skos:editorialNote "Check spelling with Thomas Vander Wal"@en.

skos:changeNote documents fine-grained changes to a concept, for the purposes of administration and maintenance:

ex:tomato skos:changeNote 
"Moved from under 'fruits' to under 'vegetables' by Horace Gray"@en.

It is important to notice that the hierarchical link between skos:note and its different specializations allows all the documentation associated with a concept to be retrieved in a straightforward way. Every skos:definition is a skos:note, every skos:scopeNote is a skos:note, and so on.

As illustrated above, SKOS documentation properties can be simply used with RDF plain literals. Section 4.2 will show that there are other possible patterns, as the range of these properties is not be restricted to literals. One important feature of simple literals, however, is the ability to use language tags, as done for labeling properties. Documentation may thus be provided in multiple languages:

ex:pineapples rdf:type skos:Concept; 
    skos:prefLabel "pineapples"@en;
    skos:prefLabel "ananas"@fr;
    skos:definition "The fruit of plants of the family Bromeliaceae"@en;
    skos:definition
           "Le fruit d'une plante herbacée de la famille des broméliacées"@fr.

Before concluding this section, it is important to note that other, non-SKOS properties could be used to document concepts. The dct:creator property from Dublin Core [DC] can for instance be used to point to a person that created the concept:

ex:madagascarFishEagle dct:creator [ foaf:name "John Smith" ].

Hat vielleicht jemand eine größere Menge verschiedener SKOS-Vokabulare in einem Triple Store? Dann könnten wir mal empirisch die tatsächliche Nutzung mittels ein paar SPARQL-Queries untersuchen. @nichtich , habt ihr da was im BARTOC-Kontext?

In JSKOS sind mehrere notes pro Sprache möglich, außerdem machen wir keine inference (wenn scopeNote vorhanden, dann müste es automatisch identische note geben), d.h. S17 wenden wir nicht an.

In der BK gibt es mehrere Klassen mit mehreren notes z.B. 89.83 hat eine definition und zwei notes. Letztere könnten aber stattdessen auch scopeNote sein: die Art einer Note ist manchmal Anssichtssache.

Was die Sammlung diverser SKOS-Dateien betrifft, da haben wir irgendwo auf einem Server noch eine Menge von https://skosmos.bartoc.org herumliegen, aber das schaffe ich erst im Sommer mich wieder daran zu setzen.

2 „Gefällt mir“

Danke, für die Antwort, @nichtich . Wir werden jetzt formal auch erstmal mehrere notes erlauben. Auch wenn es formal keine Constraints gibt/geben sollte, glaube ich nicht, dass es bei allen sinnvoll wäre, mehrere Einträge zu nutzen. Z.B. denke ich, dass für scopeNote und example wie auch für definition eine Festlegung auf ein Literal pro Sprache sinnvoll ist. In SkoHub könnten wir dann mit einer Warning entsprechend darauf hinweisen. Ich fänd es nur super, wenn sowas auch mal als Best Practice/Community Pattern irgendwo festgehalten wäre.

Ich meine bei der DDC gibt es wie bei der BK auch mehrere notes einer Sprache und das kann schon Sinn machen wenn mehrere Hinweise angezeigt werden. Im Grunde handelt es sich dabei um eine Liste von mehreren Punkten die beachtet werden sollen. Beispiel:

a:concept skos:changeNote
  "2020-03-03: Definition erweitert"@de,
  "2023-05-07: Tippfehler korrigiert"@de .

Workaround der wahrscheinlich auch in der Praxis vorkommt:

a:concept skos:changeNote
  "2020-03-03: Definition erweitert\n2023-05-07: Tippfehler korrigiert"@de .

Mit Zeilenumbrüchen ist aber keine Darstellung als Liste möglich.

Ja, bei changeNote und evtl. auch historyNote ergibt das Sinn (deshalb hatte ich es im letzten Kommentar auch nicht genannt). Bei definition, example und scopeNote aber eher nicht würde ich sagen.

Meiner Meinung nacht ist definition das einzige Feld, bei dem eine Wiederholung problematisch ist (welche Definition gilt denn nun? Jede einzeln? Alle in Kombination?). Die Bedeutung von scopeNote verstehe ich so, dass das eine offene Liste sein kann (Aspekt X fällt auch unter diese Klasse, Ach ja, Y könnte hier auch rein kommt aber darauf an…).