From bb959412a27d99f3be685a51b5082ab2e189b2fd Mon Sep 17 00:00:00 2001 From: Jakob Voss Date: Mon, 13 Jan 2025 11:36:11 +0100 Subject: [PATCH] Update draft --- 0.6.0/index.html | 538 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 369 insertions(+), 169 deletions(-) diff --git a/0.6.0/index.html b/0.6.0/index.html index 3b5fb86..57b64e1 100644 --- a/0.6.0/index.html +++ b/0.6.0/index.html @@ -135,8 +135,9 @@

Table of contents

@@ -243,14 +247,28 @@

Table of contents

1 Introduction

-

JSKOS (JavaScript Object Notation for Simple Knowledge Organization Systems) defines a JavaScript Object Notation (JSON) structure to encode knowledge organization systems (KOS), such as classifications, thesauri, and authority files. JSKOS supports encoding of concepts, concept schemes, concept occurrences, and concept mappings with their common properties. It further defines application profiles for registries, distributions, and annotations. See object types for an outline.

-

The main part of JSKOS is compatible with Simple Knowledge Organisation System (SKOS) and JavaScript Object Notation for Linked Data (JSON-LD) but JSKOS can be used without having to be experienced in any of these technologies. A simple JSKOS document can be mapped to SKOS expressed in the Resource Description Framework (RDF), and vice versa. JSKOS further supports closed world statements to express incomplete information about knowledge organization systems to facilitate use in dynamic web applications.

-
-

1.1 Status of this document

-

JSKOS is currently being developed as part of project coli-conc. The JSKOS specification is hosted at http://gbv.github.io/jskos/ in the public GitHub repository https://github.com/gbv/jskos. Feedback is appreciated! See https://github.com/gbv/jskos/issues for a list of open issues.

-
-
-

1.2 Conformance requirements

+

JSKOS (JavaScript Object Notation for Simple Knowledge Organization Systems) defines a JavaScript Object Notation (JSON) structure to encode knowledge organization systems (KOS), such as classifications, thesauri, authority files, and knowledge graphs.

+

The core of JSKOS is an encoding of Simple Knowledge Organisation System (SKOS), an application of the Resource Description Framework (RDF), in JavaScript Object Notation for Linked Data (JSON-LD). JSKOS is compatible but it does not require to be experienced in any of these technologies. Another influence is the Wikibase data model, which can partly be encoded in JSKOS as well.

+
+

1.1 Outline

+

In addition to concepts and concept schemes JSKOS can express information about:

+ +

See object types for another outline.

+
+
+

1.2 Status of this document

+

JSKOS is being specified since 2016 based on actual use cases and without a committee (see changelog). The specification is hosted at http://gbv.github.io/jskos/ in the public GitHub repository https://github.com/gbv/jskos. Feedback is appreciated! See https://github.com/gbv/jskos/issues for a list of open issues.

+
+
+

1.3 Conformance requirements

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

@@ -369,7 +387,7 @@

2.9 rank

A rank is one of the strings preferred, normal, and deprecated. Applications MAY ignore or limit ranks to selected use cases.

-

Elements of a set and qualified values are expected to have a field rank with a rank value. If an element lacks a rank, its default rank is normal.

+

Elements of a set and [qualified values] are expected to have a field rank with a rank value. If an element lacks a rank, its default rank is normal.

The rank deprecated is used for elements that are known to include errors. Applications MAY filter out these elements.

The rank preferred is used to allow selection of one most relevant element from its array. Applications MAY reduce arrays of multiple elements to an array with the single element of rank preferred.

@@ -401,19 +419,23 @@

-

2.10 language range

+
+

2.10 language tag

+

A language tag is a non-empty string that conforms to the syntax of RFC 3066 language tags, limited to lowercase.

+
+
+

2.11 language range

A language range is

  • either the character “-”
    • -
  • or a string that conforms to the syntax of RFC 3066 language tags, limited to lowercase, followed by the character “-”,
    • +
  • or a language tag, followed by the character “-”,

A language range “x-”, where x is a possibly empty string, refers to the set of RFC 3066 language tags that start the string x. For instance language range en- includes language tag en, en-US, and en-GB among others. The language range - refers to all possible language tags.

A language range MUST conform to the following ABNF grammar (RFC 5234):

language-range = [language-tag] "-"
 language-tag   = 1*8alpha *("-" 1*8(alpha / DIGIT))
 alpha          = %x61-7A  ; a-z
-

JSKOS language ranges can be mapped to and from basic language ranges as defined in RFC 4647. The main difference of JSKOS language ranges is they can be distinguished from RFC 3066 based on their string value (always ending with “-”). For instance “en” could be an RFC 3066 language tag or a [RFC 3647] language range but in JSKOS it is always a language tag only:

+

JSKOS language ranges can be mapped to and from basic language ranges as defined in RFC 4647. The main difference of JSKOS language ranges is they can be distinguished from RFC 3066 based on their string value (always ending with “-”). For instance “en” could be an RFC 3066 language tag or a RFC 4647 language range but in JSKOS it is always a language tag only:

@@ -439,11 +461,11 @@

-
-

2.11 language map

+
+

2.12 language map

A language map is a JSON object in which every fields is

and

@@ -505,8 +527,8 @@

-
-

2.12 location

+
+

2.13 location

A location is a JSON object conforming to the GeoJSON specification (RFC 7946) with GeoJSON type being one of Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, or GeometryCollection. Applications MAY restrict the location data type to GeoJSON objects of GeoJSON type Point.

@@ -522,8 +544,8 @@

-

2.13 address

+
+

2.14 address

An address is a JSON object with any of the following field, each mapped to a string:

@@ -564,8 +586,8 @@

-

2.14 checksum

+
+

2.15 checksum

A checksum is a JSON object with two fields:

@@ -590,8 +612,8 @@

http://spdx.org/rdf/terms#checksumAlgorithm_sha256 for SHA-2 with 256 Bit (SHA-256).

-
-

2.15 media

+
+

2.16 media

A media is a reference to digital content such as images or other audiovisual data. The data model of JSKOS media follows the manifest resource type of IIIF Presentation API 3.0.

A media is a JSON object with at least the following fields:

@@ -615,7 +637,7 @@

@@ -804,7 +826,7 @@

- + @@ -1224,7 +1246,7 @@

qualifiedRelationsqualified relationsqualified map of qualified relations qualified relations to other resources
-

The first element of field type, if given, MUST be the item type http://www.w3.org/2004/02/skos/core#ConceptScheme.

+

The first element of array field type, if given, MUST be the item type http://www.w3.org/2004/02/skos/core#ConceptScheme.

The values of field uriPattern and notationPattern MUST conform to the regular expression syntax used by XML Schema (Appendix F) and SHOULD be anchored with ^ as first and $ as last character. Applications MAY automatically anchor unanchored regular expressions.

If concepts is a set, all its member concepts SHOULD contain a field inScheme and all MUST contain the same concept scheme in field inScheme if this field is given.

If types and concepts are sets, the types set SHOULD include all concept types for each concept’s type other than http://www.w3.org/2004/02/skos/core#Concept.

@@ -1418,7 +1440,7 @@

item type http://purl.org/cld/cdtype/CatalogueOrIndex.

+

The first element of array field type, if given, MUST be the item type http://purl.org/cld/cdtype/CatalogueOrIndex.

Registries are collection of concepts, concept schemes, concept types, concept mappings, and/or other registries.

@@ -1497,7 +1519,7 @@

The format field SHOULD reference a content format rather than its serialization and possible wrapping. The URI of JSKOS is http://format.gbv.de/jskos.

Fields mimetype, compressFormat, and packageFormat SHOULD be IANA media type URIs, if available. Field mimetype MAY be a string for backwards-compatibility.

-

The first element of field type, if given, MUST be the item type http://www.w3.org/ns/dcat#Distribution.

+

The first element of array field type, if given, MUST be the item type http://www.w3.org/ns/dcat#Distribution.

@@ -1585,7 +1607,7 @@

-

The first element of field type, if given, MUST be the item type http://rdfs.org/ns/void#Linkset.

+

The first element of array field type, if given, MUST be the item type http://rdfs.org/ns/void#Linkset.

Concordances are collections of mappings from one concept scheme to another. If mappings is a set then

  • all its members with field fromScheme MUST have the same value like concordance field fromScheme.

    • @@ -1645,7 +1667,7 @@

    A mapping represents a mapping between concepts of two concept schemes. It consists two concept bundles with additional metadata not fully defined yet.

    -

    The first element of field type, if given, MUST be an item type for mappings from the SKOS mapping properties. The field type MAY contain additional values but MUST NOT contain multiple of these values.

    +

    The first element of array field type, if given, MUST be an item type for mappings from the SKOS mapping properties. The field type MAY contain additional values but MUST NOT contain multiple of these values.

    @@ -1795,11 +1817,24 @@

-
-

4 Extended features

-
-

4.1 Qualified relations

-

Resources can be connected with qualified relations as arbitrary, typed links with optional properties. Qualified relations are a JSON object that maps relation types (each being an URI) to objects with the following fields:

+
+

4 Qualified statements

+

JSKOS defines a set of common fields (such as prefLabel, startDate, place, and media) to facilitate interoperability across diverse knowledge organization systems. Application of these fields comes with simplification and lack of context information. To allow for more details, qualified statements can express typed and qualified data at cost of interoperability.

+
+
+
+ +
+
+Note +
+
+
+

Qualified statements are similar but not identical to properties in a property graph and to referenced statements in Wikibase data model.

+
+
+

The term qualified statement refers to the combination of a property type and a qualified value. Qualified statements are grouped in qualified maps by the data type of their qualified values.

+

A qualified map is a JSON object that maps property types (each being an URI) to objects with the following fields:

@@ -1812,16 +1847,36 @@

- + - +
prefLabel language map of stringsoptional labels of the relation type, indexed by language (OPTIONAL)labels of the property type, indexed by language (OPTIONAL)
values array of qualified valuesreferences to resources (REQUIRED)qualified values of same qualified data type (REQUIRED)
-

A qualified value is a JSON object with the following fields (optional unless indicated):

+
+
+
+Example 13: Qualified map with property types from schema.org +
+
+
{
+  "https://schema.org/award": {
+    "prefLabel": { "en": "award" },
+    "values": [ ... ]
+  },
+  "https://schema.org/performerIn": {
+    "prefLabel": { "en": "performerIn" },
+    "values": [ ... ]
+  }
+}
+
+
+
+

Objects with empty array field values SHOULD be ignored.

+

A qualified value is a JSON object with the following optional fields:

@@ -1832,56 +1887,59 @@

- - - - - - + - + - + - + - + - + - +
resourceresourcelinked resource (RECOMMENDED)
startDate extended datedate when the relation started to be validdate when the statement started to be valid
endDate extended datedate when the relation ended to be validdate when the statementn ended to be valid
source setsources as evidence for the relationsources as evidence for the statement
rank rankrank of the relationrank of the statement
-

If startDate is given, the value of endDate MUST NOT be an interval with open start. If endDate is given, the value of startDate MUST NOT be an interval with open end.

-

Application MAY filter out qualified values without field resource. Elsewise the following semantics SHOULD be applied:

+

If field startDate is given in a qualified value, the value of field endDate MUST NOT be an interval with open start.

+

If field endDate is given in a qualified value, the value of startDate MUST NOT be an interval with open end.

+

In addition there are fields depending on the data type of the qualified value. These data types are:

    -
  • no field resource denotes no resource value exists (closed world)
    • -
  • field resource having the empty object ({}) as value denotes the value is unknown (open world)
    • +
  • Qualified relation for links between resources
    • +
  • Qualified date to reference related events and periods
    • +
  • Qualified literal to reference names and labels
-

Empty arrays of qualified values MUST be ignored.

-
-
-
- -
-
-Note -
-
-
-

Qualified relations are similar but not identical to properties in a property graph and to referenced statements in Wikibase data model. They should be used with caution because they increase complexity and limit interoperability.

-
-
+
+

4.1 Qualified relation

+

A qualified relation is a qualified value with the following fields (in addition to the optional fields rank, source, startDate, and endDate):

+ + + + + + + + + + + + + + + +
fieldtypedefinition
resourceresourcelinked resource (RECOMMENDED)
+

Application MAY disallow or ignore qualified relations without field resource.

-Example 13: Concept with qualified relations (from Wikidata) +Example 14: Concept with qualified relations (from Wikidata) 
{
@@ -1916,16 +1974,157 @@
+
+

4.2 Qualified date

+

A qualified date is a qualified value with the following fields (in addition to the optional fields source and rank) to express information about an event:

+ + + + + + + + + + + + + + + + + + + + +
fieldtypedefinition
dateextended datedate value of the event (RECOMMENDED)
placesetplace(s) of the event (OPTIONAL)
+
+
+
+Example 15: Qualified date of the fall of Constantinople +
+
+
{
+  "date": "1453-04-06/1453-05-29",
+  "place": {
+    "uri": "http://www.wikidata.org/entity/Q16869",
+    "prefLabel": { "en": "Constantinople" }
+  }
+}
+
+
+
+
+
+
+ +
+
+Note +
+
+
+

Optional fields startDate and endDate of a qualified date do not refer to the actual date but to when the date was valid. For instance the date of historic events may change with a new discovery, so date would hold the new date measure and startDate would hold the date of the discovery.

+
+
+

Applications MAY disallow or ignore qualified dates without field date.

+
+
+

4.3 Qualified literal

+

A Qualified literal is a qualified value with the following fields (in addition to the optional fields rank, source, startDate, and endDate):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
fieldtypedefinition
literalstringcharacter string of the literal (RECOMMENDED)
languagelanguage taglanguage of the literal (RECOMMENDED, set to und by default)
uriURIGlobally unique identifier of the literal (OPTIONAL)
typelist of URIURIs of types (OPTIONAL)
+ + +

The first element of array field type, if given, MUST be http://www.w3.org/2008/05/skos-xl#Label.

+

Application MAY disallow or ignore qualified literals without field literal.

+
+
+
+ +
+
+Note +
+
+
+

Qualified labels allow to express SKOS eXtension for Labels (SKOS-XL) in JSKOS.

+
+
+

Qualified statements of data type qualified literal MUST NOT use the property types http://www.w3.org/2004/02/skos/core#prefLabel, http://www.w3.org/2004/02/skos/core#altLabel, and https://www.w3.org/TR/skos-reference/#hiddenLabel but they MAY use the corresponding URIs http://www.w3.org/2008/05/skos-xl#prefLabel, http://www.w3.org/2008/05/skos-xl#altLabel, and http://www.w3.org/2008/05/skos-xl#hiddenLabel instead.

+
+
+
+Example 16: Qualified map of qualified literals +
+
+
{
+  "http://www.w3.org/2008/05/skos-xl#prefLabel": {
+    "prefLabel": { "en": "preferred label",
+    "values": [    
+      {
+        "type": [ "http://www.w3.org/2008/05/skos-xl#Label" ],
+        "literal": "İstanbul",
+        "language": "tr",
+        "rank": "preferred"
+      }, {
+        "type": [ "http://www.w3.org/2008/05/skos-xl#Label" ],
+        "literal": "Constantinople",
+        "language": "en",
+        "endDate": "1930"
+      }
+    ]
+  },
+  "https://www.wikidata.org/wiki/Property:P395": {
+    "prefLabel": { "en": "licence plate code" },
+    "values": [
+      { "literal": "34" }
+    ]
+  }
+}
+
+
+
+

5 Additional rules

5.1 Resource sameness

Two resources are same if and only if they both contain field uri with the same value. A resource without field uri is not same to any other resource.

-
+
-Example 14: Two same resources +Example 17: Two same resources 
{ "uri": "http://example.org/123", "created": "2007" }
@@ -1995,7 +2194,7 @@ 

 

 

 

-Example 15
+Example 18
 

 

 
The following concept has preferred labels and narrower concepts, but no alternative labels nor notations. Nothing is known about broader concepts, related concepts, and other possible concept properties:

@@ -2062,7 +2261,7 @@ 

 

 

-Example 16
+Example 19
 

 

 
The fields PARTS and _id in the following example can be ignored:

@@ -2478,7 +2677,7 @@ 
Additional
 

 

 

-Example 17: Integrated Authority File (GND)
+Example 20: Integrated Authority File (GND)
 

 

 
The Integrated Authority File (German: Gemeinsame Normdatei) is an authority file managed by the German National Library. This example encodes GND as JSKOS concept scheme with explicit knowledge about existence of more identifiers, definitions, and preferred labels:

@@ -2519,7 +2718,7 @@ 
Additional
 

 

 

-Example 18: GND Concept
+Example 21: GND Concept
 

 

 
{
@@ -2552,7 +2751,7 @@ 
Additional
 

 

 

-Example 19: DDC Concept
+Example 22: DDC Concept
 

 

 
A concept from the Dewey Decimal Classification, German edition 22:

@@ -2610,7 +2809,7 @@ 
Additional
 

 

 

-Example 20: DDC Concept
+Example 23: DDC Concept
 

 

 
A concept from the abbridget Dewey Decimal Classification, edition 23, in three languages:

@@ -2691,7 +2890,7 @@ 
Additional
 

 

 

-Example 21: DDC Concept
+Example 24: DDC Concept
 

 

 
A decomposed DDC number for medieval cooking:

@@ -2719,7 +2918,7 @@ 
Additional
 

 

 

-Example 22: Mappings
+Example 25: Mappings
 

 

 
Multiple mappings from one concept (612.112 in DDC) to GND.

@@ -2782,10 +2981,11 @@ 
Additional

Changelog

-
-

next

+

JSKOS started in 2016 as as part of project coli-conc.

+
+

0.6.0

    -
  • Add ranks and qualified relations
    • +
  • Add ranks and qualified statements
  • Add extended dates for startDate, endDate, and relatedDate.
  • Add relatedDates to replace relatedDate
  • Clarify semantics of resource fields
    • @@ -2793,8 +2993,8 @@

    next

  • Add item field basedOn
-
-

0.5.4 (2024-09-27)

+
+

0.5.4 (2024-09-27)

  • Change JSON-LD context for spatial fields (location, place, startPlace, endPlace)
  • Add Concept field deprecated
    • @@ -2803,21 +3003,21 @@

    0.5.4 (2024-09-27)

  • Mention non-indexing concepts
-
-

0.5.3 (2024-09-18)

+
+

0.5.3 (2024-09-18)

  • Allow @context to hold an array
-
-

0.5.2 (2024-08-30)

+
+

0.5.2 (2024-08-30)

  • Allow location of type GeometryCollection
  • Fix schema.org namespace in JSON-LD context document
-
-

0.5.1 (2023-07-03)

+
+

0.5.1 (2023-07-03)

  • More precise type of inScheme, topConceptOf, mappings, occurrences
  • Add some inference rules and integrity constraints
    • @@ -2825,110 +3025,110 @@

    0.5.1 (2023-07-03)Add item fields place and media

-
-

0.5.0 (2022-08-29)

+
+

0.5.0 (2022-08-29)

  • Make clear concordance field name distributions (plural)
  • Add license, compressFormat, packageFormat, size, checksum, accessURL to distribution
  • Remove fields for undefined JSKOS-API URLs
-
-

0.4.9 (2022-01-18)

+
+

0.4.9 (2022-01-18)

  • Change format of URI in JSON Schema from URI to IRI
  • Change base format of URL in JSON Schema from URI to IRI
-
-

0.4.8 (2021-02-18)

+
+

0.4.8 (2021-02-18)

  • Add concept scheme field notationExamples
-
-

0.4.7 (2021-02-10)

+
+

0.4.7 (2021-02-10)

  • Add resource field source
  • Add item field address
  • Move startPlace/endPlace to Item and map them to schema:location
-
-

0.4.6 (2019-12-02)

+
+

0.4.6 (2019-12-02)

  • Add memberRoles
-
-

0.4.5 (2019-04-08)

+
+

0.4.5 (2019-04-08)

  • Add annotations (basic support)
-
-

0.4.4 (2018-11-02)

+
+

0.4.4 (2018-11-02)

  • Add concept scheme fields notationPattern and uriPattern
  • Add concept fields startPlace and endPlace
-
-

0.4.2 (2018-08-22)

+
+

0.4.2 (2018-08-22)

  • Move identifier field from item to resource
  • Add SKOS documentation field note to item
  • Add optional JSON Schemas
-
-

0.4.1 (2018-06-26)

+
+

0.4.1 (2018-06-26)

  • Rename distribution field to distributions
  • Allow digits in custom fields
-
-

0.4.0 (2018-06-22)

+
+

0.4.0 (2018-06-22)

  • Add Registry field occurrences
  • Add Distribution object type
  • Change rule for custom fields
-
-

0.3.2 (2018-05-29)

+
+

0.3.2 (2018-05-29)

  • Add Concept Scheme field namespace
-
-

0.3.1 (2017-11-22)

+
+

0.3.1 (2017-11-22)

  • Extend ocurrences to co-occurrences
-
-

0.3.0 (2017-11-15)

+
+

0.3.0 (2017-11-15)

  • Add occurrences
-
-

0.2.2 (2017-11-06)

+
+

0.2.2 (2017-11-06)

  • Add mappings field to Concept
-
-

0.2.1 (2017-09-27)

+
+

0.2.1 (2017-09-27)

  • Disallow empty strings except as mandatory placeholder with language ranges
  • Support composed concepts with memberSet and memberList
-
-

0.2.0 (2017-09-21)

+
+

0.2.0 (2017-09-21)

  • Rename object to resource
  • Move startDate, endDate, relatedDate, and location from Concept to Item
    • @@ -2936,27 +3136,27 @@

    0.2.0 (2017-09-21)Update JSON-LD context document

-
-

0.1.4 (2016-12-02)

+
+

0.1.4 (2016-12-02)

  • Update JSON-LD context document
  • Change definition of concept bundles to use fields memberSet/List/Choice instead of members
-
-

0.1.3 (2016-10-03)

+
+

0.1.3 (2016-10-03)

  • Change definition of “location” field to subset of GeoJSON (RFC 7946)
-
-

0.1.2 (2016-06-13)

+
+

0.1.2 (2016-06-13)

  • Add “location” field for geographic coordinates
-
-

0.1.1 (2016-05-20)

+
+

0.1.1 (2016-05-20)

  • Make field “license” a set instead of a single URI
  • Add field “extent”