diff --git a/datavoc/vocabulary.rdf b/datavoc/vocabulary.rdf index 02f286a..20692e8 100644 --- a/datavoc/vocabulary.rdf +++ b/datavoc/vocabulary.rdf @@ -12,31 +12,31 @@ PROF - This is a specification corresponding to a profile of PROF used to capture an interoperable specification. Corresponds to the rules INSPEC-1 — INSPEC-10. + This is a specification corresponding to a profile of PROF used to capture an interoperable specification. Corresponds to the PROF rules. RDFS - This is a specification corresponding to a profile of RDFS used to capture an expression of data vocabularies. Corresponds to the rules DV-1 — DV-6. + This is a specification corresponding to a profile of RDFS used to capture an expression of data vocabularies. Corresponds to the DV rules. SKOS - This is a specification corresponding to a profile of SKOS used to capture an expression of terminologies. Corresponds to the rules TE-1 — TE-5. + This is a specification corresponding to a profile of SKOS used to capture an expression of terminologies. Corresponds to the TE rules. SHACL - This is a specification corresponding to a profile of SHACL used to capture an expression of application profiles. Corresponds to the rules AP-1 — AP-16. + This is a specification corresponding to a profile of SHACL used to capture an expression of application profiles. Corresponds to the AP rules. SVG - This is a specification corresponding to a profile of SVG used to capture an expression of diagrams for interoperable specifications. Corresponds to the rules SVG-1 — SVG-5. + This is a specification corresponding to a profile of SVG used to capture an expression of diagrams for interoperable specifications. Corresponds to the SVG rules. @@ -44,32 +44,23 @@ A shape or profile is a variant of another if it relaxes some of its constraints - - - - - - - - - - - - - - - - + + refines A shape refines another by adding additional constraints to it - - - + + + + + + + + reuses diff --git a/datavoc/vocabulary.ttl b/datavoc/vocabulary.ttl index df66778..c488b25 100644 --- a/datavoc/vocabulary.ttl +++ b/datavoc/vocabulary.ttl @@ -14,31 +14,31 @@ inspec: a owl:Ontology ; inspec:PROF a dct:Standard ; rdfs:label "PROF"@en ; rdfs:isDefinedBy inspec: ; - rdfs:comment "This is a specification corresponding to a profile of PROF used to capture an interoperable specification. Corresponds to the rules INSPEC-1 — INSPEC-10."@en ; + rdfs:comment "This is a specification corresponding to a profile of PROF used to capture an interoperable specification. Corresponds to the PROF rules."@en ; rdfs:seeAlso . inspec:RDFS a dct:Standard ; rdfs:label "RDFS"@en ; rdfs:isDefinedBy inspec: ; - rdfs:comment "This is a specification corresponding to a profile of RDFS used to capture an expression of data vocabularies. Corresponds to the rules DV-1 — DV-6."@en ; + rdfs:comment "This is a specification corresponding to a profile of RDFS used to capture an expression of data vocabularies. Corresponds to the DV rules."@en ; rdfs:seeAlso . inspec:SKOS a dct:Standard ; rdfs:label "SKOS"@en ; rdfs:isDefinedBy inspec: ; - rdfs:comment "This is a specification corresponding to a profile of SKOS used to capture an expression of terminologies. Corresponds to the rules TE-1 — TE-5."@en ; + rdfs:comment "This is a specification corresponding to a profile of SKOS used to capture an expression of terminologies. Corresponds to the TE rules."@en ; rdfs:seeAlso . inspec:SHACL a dct:Standard ; rdfs:label "SHACL"@en ; rdfs:isDefinedBy inspec: ; - rdfs:comment "This is a specification corresponding to a profile of SHACL used to capture an expression of application profiles. Corresponds to the rules AP-1 — AP-16."@en ; + rdfs:comment "This is a specification corresponding to a profile of SHACL used to capture an expression of application profiles. Corresponds to the AP rules."@en ; rdfs:seeAlso . inspec:SVG a dct:Standard ; rdfs:label "SVG"@en ; rdfs:isDefinedBy inspec: ; - rdfs:comment "This is a specification corresponding to a profile of SVG used to capture an expression of diagrams for interoperable specifications. Corresponds to the rules SVG-1 — SVG-5."@en ; + rdfs:comment "This is a specification corresponding to a profile of SVG used to capture an expression of diagrams for interoperable specifications. Corresponds to the SVG rules."@en ; rdfs:seeAlso . inspec:variant a rdf:Property ; @@ -58,9 +58,12 @@ inspec:refines a rdf:Property ; rdfs:isDefinedBy inspec: ; rdfs:comment "A shape refines another by adding additional constraints to it"@en ; rdfs:subPropertyOf dcterms:relation ; - rdfs:domain sh:Shape ; - rdfs:range sh:Shape ; - rdfs:seeAlso prof:isProfileOf . + rdfs:domain [ + owl:unionOf (sh:Shape prof:Profile) + ] ; + rdfs:range [ + owl:unionOf (sh:Shape prof:Profile) + ]. inspec:reuses a rdf:Property ; rdfs:label "reuses"@en ; diff --git a/docs/ap.md b/docs/ap.md index 636f1e0..cf887bb 100644 --- a/docs/ap.md +++ b/docs/ap.md @@ -20,7 +20,7 @@ Let's clarify the words we are using in SHACL-INSPEC: ## Application Profile expression -If you have not already, take a look at the [sixteen rules of SHACL-INSPEC](rules.md#rules-for-application-profiles---shacl-inspec). +If you have not already, take a look at the [fifteen rules of SHACL-INSPEC](rules.md#rules-for-application-profiles---shacl-inspec). These rules may be a bit hard to take in, especially since SHACL is a complex language. Hence, below we list what is to be expected based on the application profile as a whole as well as on the shapes. First of all, for simplicity the requirement on multilinguality are not written explicitly below, i.e. labels, description / definition and usage note are all expected to be expressed with a language and potentially translated into several languages. @@ -35,16 +35,13 @@ The following information MUST be provided for an application profile resource: * The application profile resource must have a stable identity in the form of a URI (subject position in triples) * The application profile resource must be typed as `prof:Profile` * A label expressed via the property `sh:name` -* A list of public node shapes indicated via the property `dcterms:hasPart` -* A list of public property shapes indicated via the property `dcterms:hasPart` The following information SHOULD/MAY be provided: -* A list of all classes and properties used in the application profile, indicated via the properties `inspec:reuses` or `inspec:introduces` * A description / definition expressed via the property `sh:description` * A usage note expressed via the property `skos:scopeNote` * A reference to another application profile that expresses that it is a - * "subprofile" of another profile via `prof:isProfileOf` + * "subprofile" of another profile via `inspec:refines` * "variant of" another profile via the `inspec:variant` Note that for B being a subprofile of A: @@ -54,6 +51,15 @@ Note that for B being a subprofile of A: Note also that the concepts of Application profiles being subprofiles and variant of each other of are exclusive since for the variant relation there is a requirement that at least one of the node shapes has to be a variant. +### Interoperable specification resource + +The following information derived from the Application Profile MAY be provided for a profil interoperable specification resource: + +* A list of public node shapes in the application profile, indicated via the property `dcterms:hasPart` +* A list of public property shapes in the application profile, indicated via the property `dcterms:hasPart` +* A list of all classes and properties used in the application profile, indicated via the properties `inspec:reuses` or `inspec:introduces` +* A relation, indicated via the `prof:isProfileOf` property, to any specification introducing an application profile for which there is a subprofile relation from the application profile + ### Main and supportive node shapes Note that there are node shapes of more technical nature that are excluded from the requirements below, all those must have a `sh:severity` set to `sh:INFO` or `sh:WARNING`. For example this covers node shapes pointed to via `sh:node` used to express more complex constraints such as indicating which terminology to choose concepts from. diff --git a/docs/bootstrapping.md b/docs/bootstrapping.md index f769c0b..e9c03b9 100644 --- a/docs/bootstrapping.md +++ b/docs/bootstrapping.md @@ -10,23 +10,23 @@ inspec | ## inspec:PROF -This is a specification corresponding to a profile of PROF used to capture an interoperable specification. Corresponds to the rules INSPEC-1 — INSPEC-10. +This is a specification corresponding to a profile of PROF used to capture an interoperable specification. Corresponds to the PROF rules. ## inspec:RDFS -This is a specification corresponding to a profile of RDFS used to capture an expression of data vocabularies. Corresponds to the rules DV-1 — DV-6. +This is a specification corresponding to a profile of RDFS used to capture an expression of data vocabularies. Corresponds to the DV rules. ## inspec:SKOS -This is a specification corresponding to a profile of SKOS used to capture an expression of terminologies. Corresponds to the rules TE-1 — TE-5. +This is a specification corresponding to a profile of SKOS used to capture an expression of terminologies. Corresponds to the TE rules. ## inspec:SHACL -This is a specification corresponding to a profile of SHACL used to capture an expression of application profiles. Corresponds to the rules AP-1 — AP-16. +This is a specification corresponding to a profile of SHACL used to capture an expression of application profiles. Corresponds to the AP rules. ## inspec:SVG -This is a specification corresponding to a profile of SVG used to capture an expression of diagrams for interoperable specifications. Corresponds to the rules SVG-1 — SVG-5. +This is a specification corresponding to a profile of SVG used to capture an expression of diagrams for interoperable specifications. Corresponds to the SVG rules. ## inspec:UML_OSLO diff --git a/docs/example.md b/docs/example.md index a3765b1..1152f63 100644 --- a/docs/example.md +++ b/docs/example.md @@ -78,21 +78,10 @@ ex:vi1 a prof:ResourceDescriptor ; prof:hasRole profrole:specification . ``` -The following triples can be provided as part of PROF-INSPEC, alternatively they can be auto generated as part of the harvesting process. +The following triples may be provided as part of the enrichment described in [ENRICH-INSPEC](rules.md#rules-for-enriching-the-interoperable-specifications---enrich-inspec), and are expected to be auto generated as part of the harvesting process. ```turtle -# referenced classes and properties - AP-16 -ex:spec1 inspec:reuses foaf:Document ; - inspec:reuses dcterms:title ; - inspec:reuses dcterms:created ; - inspec:reuses dcterms:publisher ; - inspec:reuses dcterms:subject ; - inspec:reuses foaf:Person ; - inspec:reuses foaf:name ; - inspec:reuses foaf:mbox ; - inspec:introduces ex:personNumber . - -# public shapes - generated as part of the harvesting process +# public shapes - ENRICH-1 ex:spec1 dcterms:hasPart ex:ns-document ; dcterms:hasPart ex:ps-title ; dcterms:hasPart ex:ps-created ; @@ -102,6 +91,17 @@ ex:spec1 dcterms:hasPart ex:ns-document ; dcterms:hasPart ex:ps-name ; dcterms:hasPart ex:ps-mbox ; dcterms:hasPart ex:ps-pnr . + +# referenced classes and properties - ENRICH-2 +ex:spec1 inspec:reuses foaf:Document ; + inspec:reuses dcterms:title ; + inspec:reuses dcterms:created ; + inspec:reuses dcterms:publisher ; + inspec:reuses dcterms:subject ; + inspec:reuses foaf:Person ; + inspec:reuses foaf:name ; + inspec:reuses foaf:mbox ; + inspec:introduces ex:personNumber . ``` ## RDFS-INSPEC expression diff --git a/docs/harvesting.md b/docs/harvesting.md index de953cd..6ada2f0 100644 --- a/docs/harvesting.md +++ b/docs/harvesting.md @@ -1,16 +1,16 @@ # Harvesting interoperable specifications -The starting point when you harvest is an expression according to PROF-INSPEC, see rules INSPEC-1 - INSPEC-10. +The starting point when you harvest is an expression according to PROF-INSPEC, see rules PROF-1 - PROF-10. ## Native harvesting according to INSPEC profile -Below we will refer to the interoperable specification resource as INSPEC resource, see by INSPEC-1 what we require of it. +Below we will refer to the interoperable specification resource as INSPEC resource, see by PROF-1 what we require of it. ### Data vocabulary If the data vocabulary is reused, i.e. `prof:isInheritedFrom` is provided, no loading is done. If the referenced interoperable specification does not exist already in the system a warning is logged. -If the data vocabulary is not reused it is attempted to be retrieved from either the `prof:hasArtifact` value or the subject. The retrieved RDF datasource is checked against RDFS-INSPEC before being loaded into the triplestore. All classes and properties should be available in the triplestore. The ontology resource should also be available for easy access in the triplestore and also pointed to via `dcterms:subject` from the corresponding `prof:ResourceDescriptor`. (The classes and properties will only be pointed to via the `inspec:reuses` or `inspec:introduces` properties from the INSPEC resource if they are explicitly used as indicated in the application profile, see below.) +If the data vocabulary is not reused it is attempted to be retrieved from either the `prof:hasArtifact` value or the subject. The retrieved RDF datasource is checked against RDFS-INSPEC before being loaded into the triplestore. All classes and properties should be available in the triplestore. The ontology resource should also be available for easy access in the triplestore and also pointed to via `dcterms:subject` from the corresponding `prof:ResourceDescriptor`. (The classes and properties will only be pointed to via the `inspec:reuses` or `inspec:introduces` properties from the INSPEC resource if they are explicitly used as indicated in the application profile, see below, or if the specification is a foundational interoperable specification introducing the data vocabulary.) ### Terminology @@ -20,7 +20,7 @@ If the terminology is not reused it is attempted to be retrieved from either the ### Application profile -The application is attempted to be retrieved from either the `prof:hasArtifact` value or the subject. The retrieved RDF datasource is checked against SHACL-INSPEC before proceeding. All public property and node shapes introduced in this application profile should be calculated and indicated via `dcterms:hasPart` from the INSPEC resource. Further metadata about the node and property shapes needs not be added to the triplestore directly. Only the metadata about the INSPEC resource itself from the application profile needs to be added. All classes and properties referenced from node and property shapes should be indicated via the `inspec:reuses` or `inspec:introduces` properties from the INSPEC resource. +The application is attempted to be retrieved from either the `prof:hasArtifact` value or the subject. The retrieved RDF datasource is checked against SHACL-INSPEC before proceeding. All public property and node shapes introduced in this application profile should be calculated and indicated via `dcterms:hasPart` from the INSPEC resource. Further metadata about the node and property shapes needs not be added to the triplestore directly. Only the metadata about the INSPEC resource itself from the application profile needs to be added. All classes and properties referenced from node and property shapes should be indicated via the `inspec:reuses` or `inspec:introduces` properties from the INSPEC resource. If there is a second application profile referenced via an `inspec:refines` relationship, then this should also be added as a `prof:isProfileOf` relation from the INSPEC resource. ### Diagram diff --git a/docs/rules.md b/docs/rules.md index d531b42..9f22d5e 100644 --- a/docs/rules.md +++ b/docs/rules.md @@ -1,12 +1,13 @@ # Rules for interoperable specifications -The rules for interoperable specifications are divided into five parts: +The rules for interoperable specifications are divided into six parts. The first five apply to anyone creating or distributing an interoperable specification, the last one applies mainly to actors harvesting interoperable specifications: 1. Rules for interoperable specifications - PROF-INSPEC - based on [[[DX-PROF]]] 2. Rules for data vocabularies - RDFS-INSPEC - based on [[[RDF-SCHEMA]]] -3. Rules for terminologies - SKOS-INSPEC - based on [[[SKOS-REFERENCE]]]] +3. Rules for terminologies - SKOS-INSPEC - based on [[[SKOS-REFERENCE]]] 4. Rules for application profiles - SHACL-INSPEC - based on [[[SHACL]]] -5. Rules for diagrams - SVG-INSPEC - based on [[[SVG11]]] +5. Rules for diagrams - SVG-INSPEC - based on [[[SVG11]]] +6. Rules for enriching the interoperable specifications - ENRICH-INSPEC ## Rules for interoperable specifications - PROF-INSPEC @@ -14,25 +15,25 @@ The rules for interoperable specifications are divided into five parts: For a specification to be considered a interoperable specification the following must apply: -> **Rule INSPEC-1:** The "interoperable specification resource" and its parts MUST have URIs and be described with PROF, the interoperable specification resource MUST be typed as `prof:Profile` or `dcterms:Standard` and have a `dcterms:conformsTo` point to `inspec:PROF` +> **Rule PROF-1:** The "interoperable specification resource" and its parts MUST have URIs and be described with PROF, the interoperable specification resource MUST be typed as `prof:Profile` or `dcterms:Standard` and have a `dcterms:conformsTo` point to `inspec:PROF` -> **Rule INSPEC-2:** All specification parts MUST be indicated via the `prof:hasResource` property from the interoperable specification and be typed as `prof:ResourceDescriptor`. An interoperable specification part MAY be a data vocabulary, a terminology, an application profile or a diagram. Other parts may exist but have no prescribed meaning by the interoperable specification profile. +> **Rule PROF-2:** All specification parts MUST be indicated via the `prof:hasResource` property from the interoperable specification and be typed as `prof:ResourceDescriptor`. An interoperable specification part MAY be a data vocabulary, a terminology, an application profile or a diagram. Other parts may exist but have no prescribed meaning by the interoperable specification profile. -> **Rule INSPEC-3:** Each data vocabulary MUST be detected by `dcterms:conformsTo` pointing to `inspec:RDFS` and MUST be possible to interpret as RDFS-INSPEC. +> **Rule PROF-3:** Each data vocabulary MUST be detected by `dcterms:conformsTo` pointing to `inspec:RDFS` and MUST be possible to interpret as RDFS-INSPEC. -> **Rule INSPEC-4:** Each terminology MUST be detected by `dcterms:conformsTo` pointing to `inspec:SKOS` and MUST be possible to interpret as SKOS-INSPEC. +> **Rule PROF-4:** Each terminology MUST be detected by `dcterms:conformsTo` pointing to `inspec:SKOS` and MUST be possible to interpret as SKOS-INSPEC. -> **Rule INSPEC-5:** Each application profile MUST be detected by `dcterms:conformsTo` pointing to `inspec:SHACL` and MUST be possible to interpret as SHACL-INSPEC +> **Rule PROF-5:** Each application profile MUST be detected by `dcterms:conformsTo` pointing to `inspec:SHACL` and MUST be possible to interpret as SHACL-INSPEC -> **Rule INSPEC-6:** A diagram MUST be detected by `dcterms:conformsTo` property pointing to `inspec:SVG` and MUST follow SVG-INSPEC +> **Rule PROF-6:** A diagram MUST be detected by `dcterms:conformsTo` property pointing to `inspec:SVG` and MUST follow SVG-INSPEC -> **Rule INSPEC-7:** A **foundational** interoperable specification MUST contain at least one data vocabulary or one terminology, MUST NOT contain an application profile and MUST be typed as `dcterms:Standard` +> **Rule PROF-7:** A **foundational** interoperable specification MUST contain at least one data vocabulary or one terminology, MUST NOT contain an application profile and MUST be typed as `dcterms:Standard` -> **Rule INSPEC-8:** A **profile** interoperable specification MUST contain at least one application profile and MUST be typed as `prof:Profile` +> **Rule PROF-8:** A **profile** interoperable specification MUST contain at least one application profile and MUST be typed as `prof:Profile` -> **Rule INSPEC-9:** A profile interoperable specification MUST list all data vocabularies and terminologies it **uses** in the application profile explicitly as interoperable specification parts +> **Rule PROF-9:** A profile interoperable specification MUST list all data vocabularies and terminologies it **uses** in the application profile explicitly as interoperable specification parts -> **Rule INSPEC-10:** Interoperable specification parts that are **reused** (as opposed to **introduced**) SHOULD indicate that by referring to the interoperable specification where they where introduced via the `prof:isInheritedFrom` property +> **Rule PROF-10:** Interoperable specification parts that are **reused** (as opposed to **introduced**) SHOULD indicate that by referring to the interoperable specification where they where introduced via the `prof:isInheritedFrom` property ## Rules for data vocabularies - RDFS-INSPEC @@ -48,7 +49,7 @@ RDFS-INSPEC builds on top of the RDF Schema specification by providing the follo > **Rule DV-5:** Classes and properties from other vocabularies MAY be included in the RDF Dataset, e.g. when being pointed to via `rdfs:subClassOf` and `rdfs:subProperty`, but MUST NOT point to the same "data vocabulary resource" via the `rdfs:isDefinedBy` property -> **Rule DV-6:** The "data vocabulary resource" MUST be indicated via the `dcterms:subject` property from the "interoperable specification part" (introduced in Rule INSPEC-2). +> **Rule DV-6:** The "data vocabulary resource" MUST be indicated via the `dcterms:subject` property from the "interoperable specification part" (introduced in Rule PROF-2). ## Rules for terminologies - SKOS-INSPEC @@ -62,7 +63,7 @@ SKOS-INSPEC builds on top of the SKOS specification by providing the following a > **Rule TE-4:** All concepts, collections as well as the terminology resource MUST have URIs -> **Rule TE-5:** The "terminology resource" MUST be indicated via the `dcterms:subject` property from the "interoperable specification part" (introduced in Rule INSPEC-2). +> **Rule TE-5:** The "terminology resource" MUST be indicated via the `dcterms:subject` property from the "interoperable specification part" (introduced in Rule PROF-2). ## Rules for application profiles - SHACL-INSPEC @@ -70,7 +71,7 @@ SHACL-INSPEC builds on top of the SHACL specification by providing additional re > **Rule AP-1:** An application profile MUST be expressed in a single RDF Dataset[2] -> **Rule AP-2:** There MUST be a single "application profile resource" with a URI in the RDF Dataset AND it MUST be the same as the "interoperable specification resource" (introduced in Rule INSPEC-1) +> **Rule AP-2:** There MUST be a single "application profile resource" with a URI in the RDF Dataset AND it MUST be the same as the "interoperable specification resource" (introduced in Rule PROF-1) > **Rule AP-3:** All property shapes with a severity of `sh:VIOLATION` and with at least one constraint (`sh:and` for specialization does not count) are considered **public** and they MUST have URIs @@ -88,17 +89,16 @@ SHACL-INSPEC builds on top of the SHACL specification by providing additional re > **Rule AP-10:** A node shape *B* MAY express that it is a **variant** of a public node shape *A* via the `inspec:variant` property only if for every property shape *X* in *A* either *X* or *Y* is in *B* where *Y* is a refinement or a variant of *X*. At least one of the property shapes must be a variant and not a refinement. -> **Rule AP-11:** An application profile *B* MAY express that it is a **subprofile of** of an application profile *A* via the `prof:isProfileOf` property only if for every node shape *X* in *A* there is a refined node shape *Y* in *B*. +> **Rule AP-11:** An application profile *B* MAY express that it is a **subprofile of** of an application profile *A* via the `inspec:refines` property only if for every node shape *X* in *A* there is a refined node shape *Y* in *B*. > **Rule AP-12:** An application profile *B* MAY express that it is a **variant** of a application profile *A* via the `inspec:variant` property only if for every node shape *X* in *A* there is a variant or refined node shape *Y* in *B*, at least one of the node shapes must be a variant and not a refinement. > **Rule AP-13:** All shapes of the application profile MUST point to the "application profile resource" via the `rdfs:isDefinedBy` property -> **Rule AP-14:** Shapes used for refinement or for variants MAY reside in other RDF Datasets as long as the dataset is pointed to via `owl:imports` AND there is either a `prof:isProfileOf` or a `inspec:variant` relation between the application profile resources. +> **Rule AP-14:** Shapes used for refinement or for variants MAY reside in other RDF Datasets as long as the dataset is pointed to via `owl:imports` AND there is either a `inspec:refines` or a `inspec:variant` relation between the application profile resources. > **Rule AP-15:** Shapes from other application profiles used for refinement or for variants MAY be included in the RDF Dataset but MUST NOT point to the same "application profile resource" via the `rdfs:isDefinedBy` property -> **Rule AP-16:** All classes and properties referred to via shapes SHOULD be explicitly indicated from the "application profile resource". The indication should use `inspec:reuses` if the referred resource is part of a **reused** specification part (see Rule INSPEC-10), otherwise `inspec:introduces` should be used. ## Rules for diagrams - SVG-INSPEC @@ -114,6 +114,18 @@ SVG-INSPEC builds on top of SVG to provide a way to clarify whether objects in a > **Rule SVG-5:** An element with type node-shape that is also public MAY have a custom data attribute on the form `data-inspec-weight="WEIGHT"` where WEIGHT is either "main" or "supportive" according to rule AP-5. +## Rules for enriching the interoperable specifications - ENRICH-INSPEC + +This set of rules aim to enrich the interoperable specification by analysing the contents of, and interaction between, the different interoperable specification parts in order to surface information which may be valuable for a webb of interoperable specifications. + +> **Rule ENRICH-1:** Every public property or node shape MAY be pointed to from the "interoperable specification resource" (introduced in Rule PROF-1) via the `dcterms:hasPart` property. + +> **Rule ENRICH-2:** For a profile interoperable specification all classes and properties referred to via shapes MAY be explicitly indicated from the "interoperable specification resource". The indication SHOULD use `inspec:reuses` if the referred resource is part of a **reused** specification part (see Rule PROF-10), otherwise `inspec:introduces` SHOULD be used. + +> **Rule ENRICH-3:** For a foundational interoperable specification all classes and properties defined by (see Rule DV-3) an **introduced** data vocabulary MAY be explicitly indicated from the "interoperable specification resource" using `inspec:introduces`. + +> **Rule ENRICH-4:** If a `inspec:refines` relation is present in the application profile resource the specification introducing the refined application MAY be indicated from the "interoperable specification resource" using `prof:isProfileOf`. +
  1. Both RDFS and SKOS introduce building blocks (classes and properties) for defining things (other classes, properties, concepts, collections) in an open world manner. However, both vocabularies and terminologies needs to work in the context of semantic specifications where it is stated explicitly what is included, hence it corresponds to a closed world perspective. Hence, in both RDFS-INSPEC and SKOS-INSPEC there is a restriction to assume that everything needed is provided in the indicated RDF Datasets. ↩1↩2