Define exactly what an OSLO code is

[RubenVerborgh]

As indicated in #12, there is uncertainty about what an OSLO code exactly is.

The informative spec says (translated from Dutch):

2.3.2 Metadata type
2.3.2.1 Code
The code is used to point to the key that appears in a certain list published by a certain source. This entity is typically used in order to [sic] types, statuses, or other attributes with a predefined number of options.

However, in #12, @madnificent remarked that “[the] informative specification may be out of sync with the formal spec.”

And indeed, the ontology in this repository currently states:

The Conceptual Model includes a 'Code' datatype that is used for the types of relation and membership properties. This is expressed using the SKOS vocabulary with a particular 'code' usually being a oslo:Code which is a skos:Concept that is part of a scheme.

So concluding, neither text defines what an OSLO code exactly is—they only describe part of its usage (and the descriptions are conflicting).

What is the exact definition of an OSLO code?
If we find this definition, it should probably be added to the spec.

[laurensdv]

An OSLO:Code is a kind of container to refer to codes that are defined in a scheme or list and has a set of required properties to indicate the origin, version and description of each particular code.

As in accordance with Core Vocabularies, oslo:Code and the concept 'code' as defined in OSLO are (supposed to be) compliant with the definition of:

http://www.w3.org/TR/vocab-regorg/#ref_rov_orgActivity
http://www.w3.org/TR/vocab-regorg/#ref_rov_orgStatus
http://www.w3.org/TR/vocab-regorg/#ref_rov_orgType

All have as a range skos:Concept, these properties are reused in the OSLO vocabulary,
and therefore oslo:Code is defined as a subclass of skos:Concept.

If we take the last example the explanation of the rov:orgType property indicates:
"That said, each jurisdiction will have a limited set of recognized company types and these should be expressed in a consistent manner in a SKOS Concept Scheme."

Note the notion of limited set. All codes that are part of a limited/controlled set should be put (conceptually) in an OSLO:Code container to be compliant with OSLO, therefore until now the URI of each such container was categorized as being of the 'oslo:Code' type.

[RubenVerborgh]

Thanks, @laurensdv. I don't mean to be picky, but a code actually being a container of codes seems to be strange. So an OSLO code is not a code, but a container?

That seems highly confusing and problematic: because if it is only a container, how do we capture the actual codes then?

While I appreciate the compliance argument, I don't think we should discuss this yet; let's first get us straight what an OSLO code is—not on the ontological level, but simply on the definition level.

[laurensdv]

That's correct, OSLO doesn't define a new kind of code as such just how an existing code needs to be exchanged. Therefore saying that it is a container isn't entirely correct either. OSLO defines how existing codes need to be exchanged between applications.

It is not a container of multiple codes either, it has metadata for another single code.

Saying a code is an OSLO:Code means that it complies to the standard and includes all required properties as defined in the specification.

[RubenVerborgh]

…which brings me back to my initial question: what is the exact definition of an OSLO code?

[nvdk]

@laurensdv that is indeed how we interpreted the formal specification. I think this issue can be closed with this clarification. Perhaps it should be added to the informal spec in a later revision to avoid confusion. Thanks

[RubenVerborgh]

Please don't close this issue yet. My question was about an exact definition of an OSLO code, which has not been answered so far. Yes, I have received statements saying what a code does, means, inherits, etc., but not what it is.

It's impossible to use this part of the OSLO vocabulary, if we don't know what it is.
If it is difficult or impossible to come up with such a definition, this is likely a sign of a deeper problem in the OSLO vocabulary.

[laurensdv]

That's basically what OSLO does, it does not introduce any new definitions. OSLO defines (conceptually) how existing information should be exchanged using its domain model and specification and explains for which type of resource each entity of the domain model is intended and what each entity means.

To facilitate developers, two serializations (formalizations) have been developed: an XML spec and an RDF spec conform to this specification.

[RubenVerborgh]

If you introduce a class in an ontology, you introduce a definition.
So really, we need to have a clear definition for an OSLO code.

The reason I'm hammering on this is that I believe there is a more fundamental problem with OSLO code. At the moment, the concept is too vague and causes issues, because nobody seems exactly sure what it is and how it should be used. As long as there is no definition for an OSLO code, the RDF spec is unfortunately broken.

[laurensdv]

Personally, I am in favor of falling back to skos:Concept if OSLO code is disambiguous.

I don't see a problem in rewrapping an existing code (originating from a controlled/limited list) with additional metadata as oslo code conceptually does.

[RubenVerborgh]

If no definition can be found, removing oslo:Code and falling back to skos:Concept is great.

Note that I don't see a problem with the wrapping either; I only see a problem with using concepts that are not defined. (But having to define a “code” as ”something that wraps a code” seems to indicate an incorrectly chosen term, i.e., maybe it needs to be oslo:CodeContainer or something then… which is exactly why I'm asking for a definition here 😉)