What is "profile container"?

[Sveino]

What is meant by "profile container"?

[Sveino]

We would like to be compliant with DX-PROF, but did not managed to write the full spec. We have for NC 2.3.1 added this insistence file based on profile.ttl . We are planning to have RDFS that represent the vocabulary so that we can re-use the same vocabulary in multiple profiles/schema.
Currently we have automatic generated SHACL from the UML and then we have the manual created, to separate them we have two instance files with their own version. We have also added header validation.
This was a direction we wanted to go, but was afraid software vendors would reject this. However, they open issue in the SV-IOP and this was then resolved/address in NC 2.3.1. We can disuse if we would like to produce it for CGMES 3.0 as well.

[VladimirAlexiev]

• Ok, I know the GeoSPARQL profiles.
• But I still don't grok why CGMES SHACL are split in two.
• Upload NC r2.3.1 #3 asks to upload CN 2.3.1 that will have an example of such "profile container"

[Sveino]

If we are able to establish a mastering source for the SHACL we do not need to two. We are now splitting them between what is generated by CimSyntaxGen (simple) and what is manual (complex).
I know that you know GeoSPARQL, I was referring to the exact file in GeoSPARQL that we are referring to by "profile container". We will now refer to that as the profile, and that link to the relevant vocabulary, constraints, validation and documentation.

[VladimirAlexiev]

@Sveino and @griddigit-ci

link to the relevant vocabulary, constraints, validation and documentation.
Yes! that bundle of resources is very useful to people.

• The GeoSPARQL profiles also state what functions and serializations (literals) are supported.
• In CIM you have cims:belongsToCategory or xx:Package (see Mis-declared Packages #12): should we also represent these as "profiles"?
  • They subdivide the totality of CIM terms into disjoint "packages", i.e. each term is in one "package"
  • The individual ontology files (eg EQ, EQBD etc) also subdivide the totality:
    • The division is not disjoint, that's the reason for Duplication Between Ontologies #5
    • They reuse the smaller "packages" to form bigger "application profiles" (if I'm not mistaken about the name).
    • There's no formal relation between each ontology and its terms
      (it is common practice to have rdfs:isDefinedBy in each term, but CIM doesn't have such links.