OWA / CWA

[ulsw]

• What is the intention of introducing CWA?

4.1 Closed world statements ... Applications SHOULD support closed world statements to explicitly disable the open world assumption for selected properties and explicitly state the known absence or existence of unknown values: -- which properties? why? example!

• Which inference tool is used? Which conclusions are drawn from what?

• CWA / OWA seems to be mixed up:

1. Introduction ... JSKOS further supports closed world statements to express incomplete information about knowledge organization systems to facilitate use in dynamic web applications.

2.5 set ... If null is allowed, sets MUST be interpreted as following to support closed world statements

2.7 language map ... language maps MUST be interpreted as following to support closed world statements: ... A language range fields indicates the existence of additional, unknown values.

In my opinion, it should be "open world statements"

[VladimirAlexiev]

I think I can answer bullets 2 & 3:

• inference: that's outside the scope of the spec
• the section is called "Closed world statements" because by default the interpretation is OWA, but that section describes how you can introduce some CWA aspects (negation). Note: It also allows you to emphasize some OWA aspects, eg "prefLabel": { "-": "..." }, means "There are some prefLabels but they are not transmitted here"; whereas lack of prefLabel would mean "dunno"

As for the motivation, @nichtich please answer. You need to describe some use cases for this.

I also think there's a risk of misinterpretation: straight JSONLD->RDF convertors starting to complain that - is not a language, and labels like ... being displayed to a user

[nichtich]

The primary use case of JSKOS is to transport KOS data via JSON API (the corresponding JSKOS API is going to be specified as well, see http://api.dante.gbv.de/ for a current implementation). Applications need to know whether additional (costly) queries will result in more information or not.

• The use of null as special value to differentiate CWA and OWA is compatible with JSON-LD and could even become official standard.
• The current rule for language tags, incompatible with JSON-LD, can be discussed. Wikidata items often include no label in a wanted language or a large number of languages. Another use case is simplification of language tags, e.g en-US, en-GB ... can all be referred to as en-.

[VladimirAlexiev]

Costly

can you give some examples of that? Eg does the above-referenced API return one prefLabel, and you need another call to get more prefLabels? At the end, the examples should go into the spec, to document the intention as queried by @ulsw

Wikidata items often include no label in a wanted language or a large number of languages

Yes, and the wikibase:labels service implements a "language fallback": try langs in order, and return only 1 label. This is very convenient for SPARQL because it keeps the cardinality of each solution to one (less important in returning an entity). Language fallback is often needed by applications. I think it's worth adding such functionality to the API

en-US, en-GB ... can all be referred to as en-

I think should be en (no trailing dash) because all those langMatches("en")

risk of misinterpretation

The API should return CWA markers only when requested by the client.

[nichtich]

The API should return CWA markers only when requested by the client.

Yes, that's a good idea, especially for labels. Using null as CWA marker however is less problematic. I is motivated by a high diversity of possible numbers of connected concepts. Some systems have many top concepts and some concepts many narrower concepts so API could put a default limit on maximum number of member elements and use null as etcetera pattern.