SHACL shapes duplicate QUDT info

[VladimirAlexiev]

• Having SHACL shapes https://qudt.org/2.1/schema/shacl/qudt is admirable
• However, they duplicate info from https://qudt.org/2.1/schema/qudt

Which is problematic for several reasons:

• terms get two isDefinedBy, which is unexpected untypical use
• this leads to duplication, which can lead to inconsistency. The first one I find is:

qudt:Aspect
  rdfs:subClassOf rdfs:Resource ;
# versus
qudt:Aspect
  rdfs:subClassOf owl:Thing ;

The SHACL even defines individuals like qudt:CT_UNCOUNTABLE, which I think have no place in a SHACL file (they can be used there, but shouldn't be defined there).

What are the loading scenarios that you want to support? If you want to support loading QUDT with SHACL but without any RDFS/OWL then it's better to split into 3 files:

• qudt: term definitions
• rdfs-owl/qudt: ontological axioms
• shacl/qudt: shapes (using only terms from the sh: namespace)

[ralphtq]

Good feedback Vladimir. My responses:

1. rdfs:isDefinedBy --The OWL schema graph and the SHACL schema graph should never be in play together - one or the other should be used. In other cases, where a graph adds additional statements to any resource we could use a property is available from the vaem ontology to express how something is elaborated. This property is, vaem:isElaboratedIn, "An annotation used to reference a graph that elaborates (adds properties and axioms to) a resource".
2. qudt:CT_UNCOUNTABLE -- Our use of SHACL as a language for modeling allows instances that are intrinsic to the definition of things to be expressed. We could put such instances in a separate graph if this is an issue for certain uses of the SHACL schema for QUDT. Would the role of that graph be a VOCAB graph for the schema? The VAEM ontology defines a number of graph roles. A SCHEMA-VOCAB role would need to be added.

[VladimirAlexiev]

The OWL schema graph and the SHACL schema graph should never be in play together

I disagree here. I may well want to use RDFS/OWL inference, and at the same time validate with SHACL.

So @ralphtq and @steveraysteveray, does my proposal for splitting into 3 files makes sense?

[steveraysteveray]

@VladimirAlexiev, splitting the files as you suggest gets messy, in my opinion. owl:imports is an OWL relation, but is needed for graph management in both the OWL and SHACL collections. Also, when you say "term definitions" in the first file, do you mean just the type declarations, comments and labels, with all the relations to be found in the OWL and SHACL file? If so, then a modeler must look at two files to get a complete picture of each defined concept, right?

[VladimirAlexiev]

Yes, that's what I mean by term definitions. The problem I describe is that term definitions are duplicated.
I agree that the more you split, the harder it is to grok QUDT. So I think you should have 1 big core file with most of the stuff, and 2 light files with the two modeling alternatives.