For example, MTConnect, which is a quite important standard for I4.0 is described in this video - https://www.youtube.com/watch?v=Whsx924LiUk

Which is described here - http://23.96.237.142/wp-content/uploads/2015/10/MIL-STD-31000A-released-on-ASSIST-3-13-2013.pdf

Many technical specifications and standards have ICS which is used for classifying standards and normative documents in databases, libraries, etc. It is a hierarchical classification which consists of three levels, e.g. ICS 25.040.40. Level 1 covers 40 fields of activity in standardization, and there are sub-divided group in level 2 and level 3.

http://qifstandards.org/
https://es.slideshare.net/nfigay/standards-for-virtual-manufacturing-and-factory-of-the-future-position-and-status-of-isa-95
https://www.linkedin.com/pulse/what-future-smart-manufacturing-reference-model-dr-nicolas-figay/

The documentation provided for dcterms:hasVersion is quoted below.
"Has Version: A related resource that is a version, edition, or adaptation of the described resource.
Notes: Dublin Core: This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/). As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration."

This is intended to be used with a non-literal value but I don't think it is defined as of now. My suggestion was to have our own sto:hasEdition Probaby just as a float value as of now.

The name of the instance should be shortened, Instead of this, having something like IEC_60050.

More properties for the class sto:TechnicalCommittee should be added.

Regarding sto:hasEdition, please have a look at #33

These type of properties should have rdfs:range as xsd:anyURI, therefore the individuals that contain these properties should be fixed.

I have realized that StandardPart is not a Subclass of Standard and it seems to me like it should be but I might be wrong.

Unless there is a specific reason, there should not exist individuals which type is only owl:NamedIndividual as in this example. The individuals should always contain an rdf:type declaring which class they belong.

This is a quite important relation for the domain
https://www.isa.org/intech/20160403/
https://www.youtube.com/watch?v=OobhzbQoUnA

Property sto:hasPages has error in its' range. In some instances, ^^xsd:int is missing.

Between IEC61850 and IEC61499 described here

The Organization Instances, e.g., MIIT should be linked the Country they belong.

We need to decide on this. Do we use the year of Publication or the Parts number

The ideal way to do it is by using Protégé before pushing. But even after that, you should check with VoCol to see the errors. For example, as you can check here there is an error in the current version. So please fix the error.

The basic is to have an rdfs:label and rdfs:comment for each one of the classes and properties like in this example.

Please use this document to accomplish this task.

There is a 'Null' entity in the ontology:
<https://w3id.org/i40/sto#>
For me, it looks like the combined leftovers of several changes/deletions.

Follow a similar procedure to the one described in #1 for this without highlighting a specific relation.

TO/DOs
Create:

1. class for ICS (International Classification for Standards)
2. object property hasICS
3. instance of ICS (25.040.40)
4. property for file size for IEC_TS 62832-1:2016
5. instance of IEC_TS 62832-1:2016

Can anybody help me with the meaning and the source of information for the value of the property "has Classification"?

After the changes in the ontology this should be done to keep it up to date in LOV.

The class ISO_42010_ArchitectureDescription is declared as owl:equivalentClass to the sto:StandardizationFramework, @sebbader, could you please explain which is the rationale behind this?

To add a diagram and an example of the ontology to the readme page. This ontology can be used as a reference - https://github.com/HajoRijgersberg/OM

The class sto:Standard is now described by means of an individual. Thus, there should be investigated an option to switch to OWL2 in this case.

Some standards has an information called TRF ( Test Report Form). This TRF is a publication type and has basic details like publication date, edition etc. For example this standard has a TRF.
Just a sample how TRF template may look like :

Target Concern Please check this out

The range of dcterms:license is the class dcterms:LicenseDocument. Values used with this property have to be instances of the class LicenseDocument and therefore non-literal values as in the following example.

1 - Create an instance of the license.

sto:GPLv2 a dcterms:LicenseDocument ;
  rdfs:comment "Published under Open Content License." ;
  skos:prefLabel "OCL 1.0" ;
  rdfs:seeAlso <https://opcfoundation.org/license/gpl.htm> .

2 - Link the standard with the created instance by using the dcterms:license property.
sto:IEC_62541 dcterms:license sto:GPLv2 ;

Licenses of standards MUST be changed in this way.

In order to see the documentation in VoCol we need to have a rdfs: label and rdfs:comment to every element. In the same way is done here, but keeping the dc:description .

https://www.researchgate.net/publication/316432275_Industrie-40-Kommunikation_mit_OPC_UA

There are two (minor) conflicts in the master branch:
https://github.com/i40-Tools/StandardOntology/blob/4218e3304be0aa9d6276bca76137a73820b36aa4/sto.ttl#L2465
https://github.com/i40-Tools/StandardOntology/blob/4218e3304be0aa9d6276bca76137a73820b36aa4/sto.ttl#L3601

B2MML is the XML implementation of ISA 95. Check https://en.wikipedia.org/wiki/B2MML

https://www.dke.de/resource/blob/1711362/eafd505d1f8c242873f9e5a4959d5c67/zentrale-normen-im-rahmen-von-industrie-4-0-data.pdf

NIST concepts should not be part of the STO ontology. If the NIST Ontology does not exist then we should create a rather small ontology to represent this but never include so many concepts in the STO ontology, e.g., here.

We want to represent that the document for standard is in a certain language but dcterms:Language and dcterms:LinguisticSystem are dead ends. dcterms:Language just provides "Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646]."

To keep a consistent naming. Next, update the readme.

A modeling example with OPC UA (IEC 62541)

sto:IEC_62541 sto:hasClassification sto:SCADALevel;
sto:SCADALevel a sto:StandardClassification;
sto:SCADALevel sto:isDescribedIn sto:ISA95;
sto:ISA95 a sto:StandarizationInitiative.

sto:IEC_62541 sto:hasClassification sto:Communication;
sto:Communication a sto:StandardClassification;
sto:Communication sto:isDescribedIn sto:RAMI40;
sto:RAMI40 a sto:StandarizationInitiative. 

http://smartgridstandardsmap.com/

The following errors occur when executing the reasoner on top of the ontology.

The properties sto:hasTitle and "sto:hasImplementationFormat" should be fixed, i.e., the rdfs:range should be changed to rdfs:Literal in order to support the @en annotation.

The main aim is to understand the standard domain in order to improve the current modeling of the STO ontology. The OPC UA standard is the basis for this understanding.

Annotation properties should be removed or improved, e.g., internal ones sto:edition and external ones like skos:prefLabel

1. To use the subfigure command in latex to put one figure next to the other and to show the contrast of one entailed relation, maybe in red.
2. To make the caption of the figure consistent, i.e., AutomationML is described in the text and IEC 62741 is depicted in the figure.
3. To highlight one entailed relation, IEC 64199 with IEC 62741 which is entailed based on the OPC UA, maybe in red.

Could you please improve the readme and provide a description of what is the ontology about. Its links in the web, i.e., VoCol, LOV, version, the other ontologies that are reused, etc?

What makes then similar and what different, in terms of OWL properties and axioms, from Standards and Technical Specifications?

This document page 72.

To check how we can improve the modeling with the PROV ontology.

Recently I noticed that some of the hierarchy classes in the STO have different names but seem to describe same things, e.g. rami:LifecycleStatus, rami:LifeCycle_Status and rami:Lifecycle_Status. Therefore, I propose to conduct a careful revision of the classification names and decide on some uniformed naming in each case.

Below, there is a full list of classes which names seemed suspicious for me:

sto:Product
sto:Prodcut

rami:LifecycleStatus
rami:Lifecycle_Status
rami:LifeCycle_Status

rami:Asst
rami:Asset
rami:Assest

rami:safety
rami:Safety

rami:Communication
rami:Communications

rami:ConditionMonitoring
rami:Conditional_Monitoring


rami:AdminShellGeneral
rami:GeneralAdminShell

rami:WorkCenter
rami:Work_Centers

As of now, We do not have some property representing the sub-parts of a standard.
For example, This instance of a standard is talking about part 27 of the standard IEC 60255. We need to represent this meaningfully in the schema.

We have the property sto:hasEdition to deal with different versions of the same standard.