SKOSXL, "advanced documentation", source/contributor

[VladimirAlexiev]

We're considering JSKOS as API for @chin-rcip's Nomenclature for Museum Cataloging (http://nomenclature.info).

Does JSKOS support SKOS-XL and "advanced documentation" (i.e. nodes for notes/descriptioons)?

• These are needed because in GLAM it's important to provide Sources and Contributors at all levels of elements: concept, label and description.

Does JSKOS standardize how to represent Sources and Contributors?

• For the Getty we used dct:source, dct:contributor (and custom subprops to indicate whether the element is "preferred" or "non-preferred" for that source/contributor)
• CHIN has textual sources/contributors for now, so we use dc:source, dc:contributor.

[nichtich]

Does JSKOS support SKOS-XL and "advanced documentation" (i.e. nodes for notes/descriptions)?

No, such information must be managed in another format and simplfied to JSKOS for use in clients not aware of this metadata. A workaround may be adding custom elements.

Does JSKOS standardize how to represent Sources and Contributors?

The main use case of JSKOS is uniform distribution of KOS data but not full support of KOS management. Fields for metadata are limited to created, issued, modified, contributor, creator, and publisher. For instance a concept about the painting "Mona Lisa" could be linked to Leonardo da Vinci via related but creator would refer to the agent who created the concept.

Adding field source looks like a good idea.

[VladimirAlexiev]

So these are definitely out of scope of JSKOS and you won't consider adding them as an option?
I'm not sure Custom Elements can help because we don't have a node for the label/description.

[nichtich]

So these are definitely out of scope of JSKOS and you won't consider adding them as an option?

Adding them as an option would require clients to handle both options. Unless we specify advanced labels and description only to be allowed when simple labels and descriptions are also given, e.g.

valid JSKOS would be:

{ "prefLabel": { "en": "apple" } }
{ "prefLabel": { "en": "apple" }, "prefLabelDetails": { } }
{ "prefLabel": { "en": "apple" }, "prefLabelDetails": { "en": { "value": "apple" } } }

invalid JSKOS would be:

{ "prefLabelDetails": { "en": { "value": "apple" } } }
{ "prefLabel": { "en": "apple" }, "prefLabelDetails": { "en": { "value": "orange" } } }

Which additional properties do you need on extended labels? Are extended labels and descriptions limited to plain strings or do you need formatted content (but how map it to plain text)? We already build on the Web Annotation Data Model and may use it's Embedded textual body class. I guess it will be needed to comment on concepts and mappings anyway.

So the idea is to add a JSKOS data type "Text" and properties prefLabelDetails, altLabelDetails, descriptionDetails... (or name it prefLabelText, altLabelText, descriptionText...)

[VladimirAlexiev]

• We need simple metadata props: created modified creator contributor source
• please note there's a class skosxl:Label but no similar class for Note
• Textual Body sounds good, if we can treat its language field same as JSONLD @language
• Not so sure about using oa:Annotation to record this simple metadata
• using a variety of props like prefLabelText sounds wrong

[nichtich]

using a variety of props like prefLabelText sounds wrong

What alternatives exist?

[nichtich]

So the current idea is to add a Text object type which can be mapped to class oa:TextualBody and as:Note. skosxl:Label can be assumed to be a subclass of these, corresponding subclasses for SKOS Notes do not exist. A JSKOS Text object MUST have a field value with string value not being the empty string. The field language is optional and it MUST be derived from the key of a Text's parent object (see JSKOS language map). So these two Text objects are equivalent:

{  "en": { "value": "foo" } }
{  "en": { "value": "foo", "language": "en" } }

Or for repeatable fields:

{  "en": [ { "value": "foo" } ] }
{  "en": [ { "value": "foo", "language": "en" } ] }

A Text object MAY have a format field. Supported values include text/plain (the default if no format is given) and text/html. Applications SHOULD limit the subset of supported HTML for security reasons.

The Text class is subclass if JSKOS Resource so additional fields such as created, modified, creator, and contributor are possible (source has not been included yet, that's issue #98).

The type field SHOULD be omitted. In contrast to Open Annotations JSON-LD it MUST be an array, if given. The best class URI I could find is http://purl.org/dc/dcmitype/Text.

[nichtich]

We're considering JSKOS as API for @chin-rcip's Nomenclature for Museum Cataloging (http://nomenclature.info).

I've looked at the JSON-LD dump of Nomenclature. The data could be serialized in JSKOS as well, then use jskos-server to provide the API.

[nichtich]

Split into #115 and #114.