Harmonization with ISO/IEC concepts

[heidivanparys]

The concepts in the set of documents regarding profiles should be harmonized with the ISO/IEC concepts, as the concept of profiling is also described in ISO/IEC standards. Or as a minimum, it should be described how they relate to each other.

What is the relation between dct:Standard (A basis for comparison; a reference point against which other things can be evaluated.) on the one side and the following concepts on the other side:

normative document
document that provides rules, guidelines or characteristics for activities or their results
Note 1 to entry: The term "normative document" is a generic term that covers such documents as standards, technical specifications, codes of practice and regulations.
Note 2 to entry: A "document" is to be understood as any medium with information recorded on or in it.
Note 3 to entry: The terms for different kinds of normative documents are defined considering the document and its content as a single entity.
[ISO/IEC Guide 2:2004]

standard
document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context
Note 1 to entry: Standards should be based on the consolidated results of science, technology and experience, and aimed at the promotion of optimum community benefits.
[ISO/IEC Guide 2:2004]

technical specification
document that prescribes technical requirements to be fulfilled by a product, process or service
Note 1 to entry: A technical specification should indicate, whenever appropriate, the procedure(s) by means of which it may be determined whether the requirements given are fulfilled.
Note 2 to entry: A technical specification may be a standard, a part of a standard or independent of a standard.
[ISO/IEC Guide 2:2004]

And OGC defines specification and standard as follows:

specification
A document written by a consortium, vendor, or user that specifies a technological area with a well-defined scope, primarily for use by developers as a guide to implementation. A specification is not necessarily a formal standard.
[OGC glossary]

standard
A document that specifies a technological area with a well-defined scope, usually by a formal standardization body and process.
[OGC glossary]

This issue may be related to #367 .

[makxdekkers]

This is an interesting question, but probably one that needs to be asked at DCMI and not here.
My personal opinion, from previous involvement with Dublin Core, is that the main difference between a dct:Standard and a standard in the ISO sense is that a dct:Standard is not a document, but the concept of a set of rules, instructions or other kinds of guidance. In other words, a dct:Standard is the 'information' mentioned in Note 2 under normative document in your text above. For example, when I tell the children "No running in the corridor", that can be a dct:Standard, even if it is not written down in a 'document' of some sort.
However, I am not sure whether it is necessary to include explanations of the similarities to or differences with ISO terminology.

[kcoyle]

Agreeing with @makxdekkers. dct:Standard is an rdf class not a "thing" - it is a type (or "concept") as Makx says. ISO standard would be of type dct:Standard if one wished to code it that way in their metadata. One could include as a member of the dct:Standard class whatever one wished to (although it being RDF, that would be an identified object, but not necessarily a document).

[kcoyle]

I also agree with Makx that we may not need to harmonize with the ISO definitions, although we may also choose to, but the fact is that we should carefully scrutinize every place that we make use of the term "standard" to

1. determine if that's the correct term for what we mean
2. understand what we mean by "standard" in that context
3. define it clearly in each document and use it based on that definition throughout the document

[smrgeoinfo]

I agree this spec needs to be clear about what 'standard' means, and the term should be used consistently. The Dublin Core definition, in essence, says 'a standard is a basis or a point', neither of which is clear that the intention is 'a standard is a type' or that 'type' means 'concept'.
Perhaps some language harmonizing @kcoyle definition with ISO: 'in the context of this specification, a standard is a set of concepts that provides rules, guidelines or characteristics for activities or their results'. I'd suggest adding qualifiers along the lines of 'widely used in a community and accepted as best practice' (a pragmatic approach) or 'established by consensus and approved by a recognized body' (more aligned with ISO concept).

[smrgeoinfo]

In my opinion, the spec doesn't need to assert a normative alignment with ISO or any spec, it just needs to clearly and unambiguously define the terms used in the spec. Alignment with other vocabularies/specs is better left to guidance (not normative) documents).

[kcoyle]

@smrgeoinfo Thanks, I agree with what you say above. I didn't mean that meaning of dct:Standard is a type, I meant that the role of the class was to set a type, and a class is not a document. Obviously I wasn't clear. The dct:Standard definition is purposely vague. We had a DCMI discussion about it somewhat recently, and I can't remember now if we made any changes to the definition, but we definitely did not want to equate it with a more rigid ISO definition (e.g. "established by consensus and approved by a recognized body") because that is more formal than DCMI intends. We had a lot of discussion about how people might interpret "recognized body" and that seemed to require a definition of its own. I would rather go with your pragmatic approach.

[heidivanparys]

However, I am not sure whether it is necessary to include explanations of the similarities to or differences with ISO terminology.

It would be helpful for those involved in ISO standardization related to profiles if similarities or differences are explained. E.g. the comment below was very useful:

[...] the main difference between a dct:Standard and a standard in the ISO sense is that a dct:Standard is not a document, but the concept of a set of rules, instructions or other kinds of guidance. In other words, a dct:Standard is the 'information' mentioned in Note 2 under normative document in your text above. [...]

[heidivanparys]

The dct:Standard definition is purposely vague. We had a DCMI discussion about it somewhat recently, and I can't remember now if we made any changes to the definition, but we definitely did not want to equate it with a more rigid ISO definition (e.g. "established by consensus and approved by a recognized body") because that is more formal than DCMI intends. We had a lot of discussion about how people might interpret "recognized body" and that seemed to require a definition of its own.

To be honest, I do think it is important to have a less vague definition.

The "recognized body" part in the ISO definition being problematic is also described in Standardization - What's in a name?

That same article, and a later book by the same author, a certain Henk J. de Vries, ("Standardization: A Business Approach to the Role of National Standardization Organizations" see https://link.springer.com/book/10.1007%2F978-1-4757-3042-5 and some contents of the book on Google Books (definition list is available)) propose the following (the first article describing all arguments of why certain aspects have or have not been included in the definition):

standardization
activity of establishing and recording a limited set of solutions to actual or potential matching problems, directed at benefits for the party or parties involved, balancing their needs and intending and expecting that these solutions will be repeatedly or continuously used, during a certain period, by a substantial number of the parties for whom they are meant

and based on that

standard
approved specification of a limited set of solutions to actual or potential matching problems, prepared for the benefit of the party or parties involved, balancing their needs, and intended and expected to be used repeatedly or continuously, during a certain period, by a substantial number of the parties for whom they are meant

Could this be useful here?

[makxdekkers]

I would like to repeat my opinion that a discussion about the semantics of DCMI terms should be moved to the appropriate discussion platform at DCMI (which would that be, Karen?).
DCAT just reuses the definitions of dct:Standard and dct:conformsTo from DCMI and we have no way to change those.
If we think that, in the context of DCAT, it is necessary to have more strict definitions, then we need to create new properties and classes, e.g.
dcat:follows dcat:Guidance, where Guidance is any non-formal set of rules
dcat:respects dcat:FormalStandard where FormalStandard is a specification endorsed by a formally recognised "standards developing organization (SDO) or standards setting organization (SSO)".
However, I don't think this is necesary based on our use cases.

[kcoyle]

Makx - the Usage Board at DCMI has just concluded a round of discussions, but that's where it would have to go. I agree with you that DCMI is unlikely to adopt a more strict definition due to the fact that it serves a community that is much broader than ISO's community. The advantage of DCMI's definition is that it can also be used with formal standards, and those will be identified by their URI.

I see a kind of tension here between a desire to have semantics inherent in the properties ("dct:conformsTo" v. something more precise) and acceptance of objects as defining the precision. If the object is the identifier of an ISO standard, then the standard obviously meets the ISO definition. To me, the object is where that level of precision belongs, and trying to move the semantics to the property will 1) cause a great proliferation of properties 2) open up the possibility of conflicts between the property and the object (e.g. if property includes ISO definition of standard but the object does not). Note also that the rule for URIs in linked data is that the URI link to useful information about the object, which is where one should find a description of the type of standard that one is linking to.

[smrgeoinfo]

Since I'm interested in machine-actionable metadata, I also prefer unambiguous, logically coherent definitions that can be formalized for machine inferencing. I recognize that if the vocabulary is intended for human consumption, then such precision is not required.

[nicholascar]

@makxdekkers this issue is tagged as being related to the profiles deliverables, not DCAT.

@kcoyle: can we decide on the approach for handling this in Guidance and then see if there are any implications for the ontology? That puts this in the overall context of profile work, rather than discussion about dct:Standard and dct:conformsTo specifically.

[kcoyle]

@nicholascar Since the guidance document is not going to be providing an ontology, I don't think that this relates or can be solved by it. In other words, there will be nothing in the guidance document that would clarify the meaning or usage of dct:Standard.

[rob-metalinkage]

I would note that the ISO definition of standard is a narrower form of the DCMI version. ISO standard is not a thing - its a class of things (though of course the class definition is a thing, but that is the inherent OWL punning)

OGC has deprecated the use of standard in favour of "specification" - which avoids clashes with ISO's narrower definition and the broader range of community processes OGC supports. "specification" is probably a narrower form of dct:Standard where the rules are in fact expressed - it must have at least one supporting document. We have just got rid of "base specification" which was a specification with supporting documents that is not declared to profile anything else - i think its wise to remove it because we may simply not wish to declare what it constrains.

I am comfortable we can and should use the dct:Standard as a superclass and push any debate back to DCMI.