Have a dedicated class to type SHACL specifications (instead of owl:Ontology)

[tfrancart]

I would find it useful to have a dedicated type, other than owl:Ontology, to type SHACL specifications.
In particular in systems that manage both OWL ontologies and SHACL specifications, to distinguish them.
Also because metadata properties are attached to this entity (versions, dates, etc.)

e.g. sh:ShapesGraph (upper case S), probably a subClassOf owl:Ontology.

[HolgerKnublauch]

Yes this makes sense, also to make SHACL appear less dependent on OWL.

sh:ShapesGraph could be used but sometimes shapes graph can be part of the data graph (we do this all the time), and it's rather a role that a graph plays depending on the use case.

What about just introducing sh:Graph for now? I wouldn't make it a subclass of owl:Ontology, but rather handle it as a fresh start.

Or sh:Graph and a subclass sh:ShapesGraph to indicate that this it typically used as a shapes graph, and sh:DataGraph to indicate it contains instance data?

Introducing those is relatively cheap as they are primarily just named resources without real semantics.

And once we are there, introduce sh:imports as an alternative to owl:imports, treated with exactly the same semantics? It would have rdfs:domain sh:Graph.

[tfrancart]

What about just introducing sh:Graph for now? I wouldn't make it a subclass of owl:Ontology, but rather handle it as a fresh start.
Or sh:Graph and a subclass sh:ShapesGraph to indicate that this it typically used as a shapes graph, and sh:DataGraph to indicate it contains instance data?

I am uncomfortable with the idea of not making this new proposed entity a subClassOf owl:Ontology. It has been described in #246 how some are mixing OWL and SHACL. In such a situation, if we have ThisNewEntity subClassOf owl:Ontology, then typing it ThisNewEntity would be sufficient, otherwise a double typing ThisNewEntity + owl:Ontology would be necessary.

I am not myself using the notion of data vs. shapes graph, which, as you say, is more a role of the graph (in a validation process). Also that notion of graph may not always fit the reality, as a single graph may end up contain multiple instances of ThisNewEntity if more that one SHACL specification have been somehow merged.
Thinking about it, I am more and more referring to "SHACL Specifications", because that's what we do : we write data specs. So my suggestion would be something more "graph-neutral" : sh:ShapesSpecification.

And once we are there, introduce sh:imports as an alternative to owl:imports, treated with exactly the same semantics? It would have rdfs:domain sh:Graph.

I am also uncomfortable with this idea (which should be probably in another issue). Why redeclaring something with exactly the same semantics (except for "political" reasons) ? For OWL+SHACL use-cases, this would mean in certain situation that an import would have to made 2 times : one "the OWL way" and one "the SHACL way" ?

(note for myself : owl:versionIRI and rdfs:isDefinedBy could also be of interest for SHACL specifications)

[bergos]

For some of my use cases, I would prefer a class that is not a sub-class of owl:Ontology and instead explicitly double type when it's required.

For example, I use two shapes for the same classes in my time series data. One shape is for data modeling. It describes the allowed properties, datatypes, allowed min/max values, etc. The API refers to it for incoming data. The other shape describes the current state of the data in the store. The min/max values are further constrained. A min/max value is added to the timestamp. owl:Ontology fits very well for the first shape, but It would be good to have a class, not based on owl:Ontology, for the later shape.

[HolgerKnublauch]

@tfrancart I have no strong opinion here and can live with either solution wrt subclassing or sh:imports.

Yes, my preference is to have a cleaner fresh start for those who want to move forward with just the sh: namespace. A part of this is "political" but I believe for good reasons. See the first paragraph of #246 "a modeling language that has already had some concepts used by SHACL, OWL 2, specifically for owl:Ontology, and incidentally owl:imports." With the current spec it really gives OWL more credits than necessary and can cause confusion. There is some beauty in making a language self-contained and eliminate the need to use another namespace in SHACL graphs. Ideally we just get away with rdf:, rdfs: and xsd: as that is what SHACL is really based on (rdfs:subClassOf at least).

Parts of the design of SHACL 1.0 were intentionally limited to tiptoe around the elephant in the room, namely that many people can perfectly fine live without OWL and do ontology modeling with SHACL alone. (Changing the prose about this is another editorial issue that we should fix IMHO - SHACL is not just a validation language any more and never really was except to appease the OWL camp for political reasons.)

@bergos I am honestly not sure I understand your example. I believe the owl:Ontology and sh:XYGraph would have the same URI as the "home" location from where the graph was loaded. You seem to talk about different shapes but how does this relate to the question of the (single) home URI of the graph?

[bergos]

Maybe it's easier to explain with an example:

The following shape would be located in the named graph http://example.org/data-model. The graph would contain all the shapes one defines for data modeling. The constraints are rather open to accept any realistic data:

@prefix ex: <http://example.org/>.
@prefix sh: <http://www.w3.org/ns/shacl#>.

ex:ObservationShape a sh:NodeShape;
  sh:targetClass ex:Observation;
  sh:property [
    sh:path ex:date;
  ], [
    sh:path ex:temperature;
    sh:maxExclusive 70;
    sh:minInclusive -30;
  ].

The following shape would be located in the named graph http://example.org/current. The graph would contain shapes that describe the current state of the data in the instance/endpoint. That means all observations on the instance are measured between 2000 and 2025, with temperatures ranging from -15 to 35 degrees. The shapes of this graph can be used as hints for filtering the data without the requirement to query the complete data graph:

@prefix ex: <http://example.org/>.
@prefix sh: <http://www.w3.org/ns/shacl#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

ex:ObservationShape a sh:NodeShape;
  sh:targetClass ex:Observation;
  sh:property [
    sh:path ex:date;
    sh:maxExclusive "2025-01-01T00:00:00.000Z"^^xsd:dateTime;
    sh:minInclusive "2000-01-01T00:00:00.000Z"^^xsd:dateTime
  ], [
    sh:path ex:temperature;
    sh:maxExclusive 35;
    sh:minInclusive -15
  ].

I think both, http://example.org/data-model and http://example.org/current, are shape graphs, but only the first one is also an ontology. The attached metadata would look like this:

@prefix ex: <http://example.org/>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix sh: <http://www.w3.org/ns/shacl#>.

ex:data-model a owl:Ontology, sh:ShapeGraph;
  rdfs:label "Ontology that describes the data on this instance".

@prefix ex: <http://example.org/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix sh: <http://www.w3.org/ns/shacl#>.

ex:current a sh:ShapeGraph;
  rdfs:label "Shapes that describe the current state of the data on this instance".

[HolgerKnublauch]

@bergos thanks for the example. I now understand: not every shapes graph is also an ontology in the traditional Ontology sense.

[tfrancart]

(...) SHACL is not just a validation language any more and never really was except to appease the OWL camp for political reasons. (...)

@HolgerKnublauch ouch :-)

@bergos :

1. owl:Ontology != data model. A file with only instances (NamedIndividual in the OWL perspective) is a valid OWL file
2. I don't share your perspective on what is and what is not a data model. Both of your example are data models. Simply their coverage vary. But from an OWL/RDFS perspective maybe, only http://example.org/data-model would contain the declarations of classes and properties (if they are declared at all ?)
3. We need the ability to make SHACL specifications more modular, by reusing and extending existing specifications (e.g. overwrite a cardinality - is there an issue for this ?). For this, OWL brings some useful features with owl:imports and owl:versionIRI. In particular owl:imports has a defined semantics, and existing implementations. I was thinking that, even if SHACL does not rely on any other OWL features, these 2 predicates, and the domain they imply, could be relied on.

That being said, if the same import feature is provided in the sh namespace, I would be fine with it. The important points here are : ability to express metadata on the SHACL header entity, and ability to import specifications from other specifications.

I still suggest that a "graph-neutral" and "data-model-neutral" and "use-case neutral" naming like sh:ShapesSpecification would be appropriate to type this entity.

[ajnelson-nist]

@tfrancart I'm really glad you brought up the owl:versionIRI and owl:imports semantics and implementations. It was a holiday yesterday for me, else I would have posted on that as well. I'll be posting another Issue (I hope today) on those predicates and owl:incompatibleWith - separating out because that topic's incidental but out of scope of the question on this Issue.