Add sh:ShapeClass

[HolgerKnublauch]

Related to #169 SHACL should become more stand-alone and grow up in a formerly OWL-dominated world.

In the dash namespace we have added

dash:ShapeClass
  a dash:ShapeClass ;
  rdfs:comment "A class that is also a node shape. This class can be used as rdf:type instead of the combination of rdfs:Class and sh:NodeShape." ;
  rdfs:label "Shape class" ;
  rdfs:subClassOf rdfs:Class ;
  rdfs:subClassOf sh:NodeShape ;
.

so that classes using implicit class targets can be written with just one rdf:type instead of two:

ex:Person
    a dash:ShapeClass ;
    sh:property ex:Person-birthDate ;
...

instead of

ex:Person
   a rdfs:Class, sh:NodeShape ;
    sh:property ex:Person-birthDate ;
...

This could be leveraged into the sh: namespace as sh:ShapeClass.

[caribouW3]

Discussion Feb 24th: https://www.w3.org/2025/02/24-data-shapes-minutes.html#d570

[ajnelson-nist]

I am concerned that this proposal induces a requirement of SHACL-specific entailment to expose a non-SHACL modeling class that some systems may require to be hard-coded. If this were also trying to simplify owl:Class designations, then my understanding is this would not work with OWL's parsing algorithm. I think there is an analogous situation for general RDF, so I'll discuss the OWL bit briefly in order to come back to general RDF.

Within OWL, my understanding of the parsing algorithm described in this document is that the parsing process happens with no inferencing. Only hard-coded statements are loaded into the parsing algorithm, whether through the initialization, or through following owl:imports, and there is no point to pause and run an inferencing step.

Let's pretend through just the next code block that sh:ShapeClass also had as part of its definition sh:ShapeClass rdfs:subClassOf owl:Class .. This graph would fail to parse by the OWL algorithm (i.e., the graph is not in the OWL2 DL Profile, but instead in OWL FULL), because ex:person-1 is using an IRI that is not explicitly defined as an owl:Class:

ex:Person
    a dash:ShapeClass ;
    .

ex:person-1
    a ex:Person ;
    .

And now I've talked about OWL long enough to come back to general RDF: I don't know whether RDF parsers also in general have the same strictness of "Something in the object position of s rdf:type o must be designated a class." I imagine there's the general fallback of "Well, at least it'll be an rdfs:Resource," so even s rdf:type [] works. But it's not clear to me whether this would be fine to a parser that is not SHACL-aware:

ex:A
    a sh:ShapeClass ;
    .

ex:B
    a sh:ShapeClass ;
    rdfs:subClassOf ex:A ;
    .

I could see this raising a parse error, similar to "non-Class a part of a subclassing declaration".

I'm concerned that this effort to save a type statement through entailment would cause compatibility issues by imposing a requirement of "You need to speak SHACL to load this" on a single graph that mixes SHACL with RDFS modeling and uses sh:ShapeClass.

Meanwhile, coming back to OWL with one last remark - this proposal as written saves no effort for OWL-and-SHACL users, because it does not include sh:shapeClass rdfs:subClassOf owl:Class. Again from my understanding of the OWL parsing algorithm, I don't think that definitional statement would be of any help. So, OWL-and-SHACL users would still need the second rdf:type statement anyway.

[HolgerKnublauch]

Why should a niche technology such as OWL DL with all its well-known flaws and limitations constrain how other languages like SHACL are designed. The design mistakes that you describe are in the layering of OWL 2 on RDF. It is probably already outside of OWL DL when you use the current pattern, which is

ex:MyClass
    a rdfs:Class, sh:NodeShape .

because it uses rdfs:Class instead of owl:Class. SHACL doesn't say anything about owl:Class, and that's good. Maybe there will be an OWL 2.1 that addresses these problems, but it shouldn't be more than a nice-to-have for us here.

I am aware that individuals can veto the decisions by the group. I have done this in the past too. Therefore, can we try to work on a compromise? What about we include an informal comment that explains that in order to be friendly to OWL, you should do X and Y (which could be "don't use rdfs:Class" and "use owl:Class instead"), so that you can live with the current proposal? Or that the WG publishes a separate document on the relationship between SHACL and languages including OWL, which would then also include the variant of the SHACL definitions that you have suggested in #246 ? In general, wouldn't adding a few triples to #246 also address the sh:ShapeClass compatibility?

[ajnelson-nist]

I've apparently caused a distraction: I only meant to use OWL to illustrate a problem I think would occur outside of OWL. I do believe OWL is outside the scope of this proposal for reasons specific to OWL.

The point I wish to emphasize from my long comment is that sh:ShapeClass seems it would impose a requirement of SHACL entailment on non-SHACL RDFS users. A specific demonstration of this concern would be the following graph raising an error in some RDFS-based parser that is not SHACL aware:

ex:A
    a sh:ShapeClass ;
    .

ex:B
    a sh:ShapeClass ;
    rdfs:subClassOf ex:A ;
    .

I'm also not attempting a veto. I lead my comment with "I am concerned that...", and it's up to the group to decide whether my concern is shared.

[HolgerKnublauch]

Wouldn't RDFS entailment infer that ex:A is also an rdfs:Class because rdfs:domain/range of rdfs:subClassOf is rdfs:Class? likewise, the range of rdf:type is rdfs:Class, so as soon as there are instances of a ShapeClass it would be understood to be an rdfs:Class.

In shapes graph that only declare ex:A s sh:ShapeClass, why would an RDFS processor care what this is, as there are no inferences?

[ajnelson-nist]

Wouldn't RDFS entailment infer that ex:A is also an rdfs:Class because rdfs:domain/range of rdfs:subClassOf is rdfs:Class? likewise, the range of rdf:type is rdfs:Class, so as soon as there are instances of a ShapeClass it would be understood to be an rdfs:Class.

RDFS entailment would pick this up today, yes, as those domain and range statements are in RDF 1.1 Semantics, Section 9.

In shapes graph that only declare ex:A a sh:ShapeClass, why would an RDFS processor care what this is, as there are no inferences?

This is a good point to enumerate the constraints of the use case I'm focused on:

1. An RDFS processor,
2. that uses no inferencing,
3. loading a graph with ex:A a sh:ShapeClass as a data or ontology graph (distinction incidentally under discussion in Where should my ontology go? Data graph versus shapes graph #185 , but not a blocker here),
4. also having in the graph some "Class"-y usage of ex:A, whether x rdf:type ex:A or y rdfs:subClassOf ex:A or p rdfs:domain ex:A,
5. and flags "Undefined" (not-structurally-typed) IRIs, e.g. for typo detection or missing-import warnings.

I don't currently think SHACL-awareness is part of this constraints list. And one thing I'm really unaware of is how much point 5 is a concern to others. I've seen point 5 be a noteworthy data quality control matter.

Explaining the no-inferencing bit: I'm aware that there is a friction with full RDFS entailment and JSON-LD use cases. In short, full RDFS entailment causes an issue with serializing data after entailment, because of entailment rule rdfs4b (in 9.2.1 of the Semantics document). You then get statements like true a rdfs:Resource ., which cannot serialize to JSON-LD because the @id key's paired value must be, or expand to, an IRI. (I can't find the specific part of JSON-LD 1.1 that says this, but this exercise on the Playground flags the issue.)

My concern to the original issue, adding sh:ShapeClass, is that anything that induces an entailment requirement induces some burdens, especially on SHACL-unaware users. Full RDFS entailment causes troubles and needs for mitigations for some users, on parsing, validation, or serialization. (We don't need to discuss OWL entailment here - it turns out to be moot for another OWL-specific reason.) A SHACL-level mitigation might be possible by saying only SOME entailment is needed, like I'd described in #219 , but ultimately I think the potential for trouble outweighs the benefit of consolidating type declarations.

[HolgerKnublauch]

@ajnelson-nist thanks for the details and the discussion. I am really trying to understand the exact problem space here.

From your list of pre-conditions, what exactly do you mean with RDFS processor, if inferencing is OFF. Do you mean just some RDF (triples) processor? What sort of algorithm in particular?

Asking because if an RDF processor only knows about RDFS vocabulary, then it wouldn't even understand owl:Class, owl:Restriction etc. without having the extra rdfs:subClassOf triples from the OWL namespace. This would be the exact same solution to support SHACL and sh:ShapeClass, because the sh: namespace graph contains enough triples to make them understandable. This is not different from any other vocabulary IMHO - in order to make sense of SKOS for example, people should owl:import the SKOS namespace, so that they can learn about the property and class definitions, e.g. that skos:Concept is a class at all.

To me, sh:ShapeClass is more than just syntactic sugar. It is a way for SHACL to "grow up" into a self-contained language where ontologies can model almost everything in the sh: namespace only. The syntactic sugar does remain important too, for example in our home-grown ontologies, more than 95% of node shapes are also classes.

[HolgerKnublauch]

@ajnelson-nist as mentioned in the meeting today, we should try to conclude on this topic here on this ticket. See my comment above, I would appreciate if you could point of exact problems, exact interpretation mistakes that RDF processors would make if they only see sh:ShapeClass without its ontological definition. And if they do, is this even a valid argument: the whole point of ontologies is that people should use them to learn about classes. Even in cases like sh:NodeShape a non-SHACL processor wouldn't really understand that sh:NodeShape is an rdfs:Class without the sh graph.

[ajnelson-nist]

Replying to the last two comments:

@ajnelson-nist thanks for the details and the discussion. I am really trying to understand the exact problem space here.

From your list of pre-conditions, what exactly do you mean with RDFS processor, if inferencing is OFF. Do you mean just some RDF (triples) processor? What sort of algorithm in particular?

I only meant a triples processor that parses some concrete syntax (Turtle, JSON-LD, etc.) into a graph representation. I had no specific algorithm matters in mind, only that RDFS entailment might not be guaranteed.

Asking because if an RDF processor only knows about RDFS vocabulary, then it wouldn't even understand owl:Class, owl:Restriction etc. without having the extra rdfs:subClassOf triples from the OWL namespace. This would be the exact same solution to support SHACL and sh:ShapeClass, because the sh: namespace graph contains enough triples to make them understandable. This is not different from any other vocabulary IMHO - in order to make sense of SKOS for example, people should owl:import the SKOS namespace, so that they can learn about the property and class definitions, e.g. that skos:Concept is a class at all.

I agree with you here - the analogy with owl:Class is basically exact. The axiom owl:Class rdfs:subClassOf rdfs:Class seems to be generally available-enough that the graph at the OWL IRI doesn't need to be manually fed in to most RDF parsers as a supplement for the parser to understand "Oh, ex:A a owl:Class means ex:A's a class and I can use it with rdf:type."

To me, sh:ShapeClass is more than just syntactic sugar. It is a way for SHACL to "grow up" into a self-contained language where ontologies can model almost everything in the sh: namespace only. The syntactic sugar does remain important too, for example in our home-grown ontologies, more than 95% of node shapes are also classes.

During this "growing-up" period, I think a graph containing ex:A a sh:ShapeClass will induce an end-user requirement: To understand from ex:A a sh:ShapeClass that ex:a-1 a ex:A . is fine will need at least one of four pieces of support:

1. Accepting that x a y . implies y is implicitly an rdfs:Class, OR
2. RDFS inferencing, OR
3. Baked-in knowledge in the parser of the axiom sh:ShapeClass rdfs:subClassOf rdfs:Class ., OR
4. For the user (or data pool initializer) to supply the SHACL namespace graph (shacl.ttl) as part of their parsing.

I'm not familiar enough with the tooling space to know if specifically point 1 is generally done anyway. My concern's fairly moot if so, and I invite tool maintainers to weigh in on this.

I'm aware that full RDFS inferencing is a sufficient concern in some use cases that it's not an option (such as JSON-LD having issues with rule rdfs4b, which I'd noted above).

Point 3 happening is a social question, and I decline to speculate.

Point 4 is a small task to ask of the user, but it is a non-zero effort in cases where every o in the pattern s rdf:type o must be a recognized class concept as a condition for a graph-loading process to succeed. OWL has an analogous requirement, but happens to be out of scope of this discussion for reasons specific to OWL. (The short reason why: OWL disallows statements of the form x rdfs:subClassOf owl:Class.)

If sh:ShapeClass obscures rdfs:Class, I suspect there are some users who will need to load the sh: graph in order to parse a graph containing ex:A a sh:ShapeClass. For the best user experience, should the shapes-graph provider also encode an import statement ex:MyShapesGraph owl:imports sh: . for extra assurance that their classes will be recognized?¹

@ajnelson-nist as mentioned in the meeting today, we should try to conclude on this topic here on this ticket. See my comment above, I would appreciate if you could point of exact problems, exact interpretation mistakes that RDF processors would make if they only see sh:ShapeClass without its ontological definition. And if they do, is this even a valid argument: the whole point of ontologies is that people should use them to learn about classes. Even in cases like sh:NodeShape a non-SHACL processor wouldn't really understand that sh:NodeShape is an rdfs:Class without the sh graph.

SHACL 1.0 doesn't require loading sh: into the data graph (or ontology graph) in order to get shapes validation. Will sh:ShapeClass induce a requirement that sh: be an import dependency?

Footnotes

1. Or sh:imports, depending on how that part of Have a dedicated class to type SHACL specifications (instead of owl:Ontology) #169 plays out. ↩

[HolgerKnublauch]

Thanks for the continued discussion @ajnelson-nist. In a nutshell you seem to say "sh:ShapeClass for SHACL is the same as owl:Class for OWL, but the difference is that OWL is already established so most tools by now may know how to handle it, while no other language is allowed to enter the same group of languages from now on".

I don't think this is fair to SHACL. The situation with OWL is even worse, because there really was no strong reason to even introduce owl:Class beside syntactical pureness, while in SHACL it really "means" something because it triggers validation for SHACL processors. Further, OWL is worse because it also introduces various other metaclasses including owl:Restriction and property metaclasses like owl:DatatypeProperty and ObjectProperty. Was this needed? No, I don't think so. Did it happen regardless? Yes. So why should we block SHACL from the same benefits.

The owl:import is not needed but I think it's generally a reasonable expectation for RDF-based tools to look up ontological definitions. This is at the very heart of semantic web technology.

Overall while I acknowledge there can be corner cases where tools may have some limited understanding of sh:ShapeClass, I think the consequences of this pale in comparison to the benefits of having sh:ShapeClass generally available to everyone else, especially SHACL tools. A tool that doesn't know about SHACL wouldn't behave differently when it encounters a sh:ShapeClass anyway. SHACL is in the same category of languages as OWL and therefore has the same rights to introduce new terms.

[ajnelson-nist]

Thanks for the continued discussion @ajnelson-nist. In a nutshell you seem to say "sh:ShapeClass for SHACL is the same as owl:Class for OWL, [...]"

Yes.

"[...] but the difference is that OWL is already established so most tools by now may know how to handle it, while no other language is allowed to enter the same group of languages from now on".

I did not say that and I cannot say that. Please do not claim that I said that.

I don't think this is fair to SHACL. The situation with OWL is even worse, because there really was no strong reason to even introduce owl:Class beside syntactical pureness, while in SHACL it really "means" something because it triggers validation for SHACL processors. Further, OWL is worse because it also introduces various other metaclasses including owl:Restriction and property metaclasses like owl:DatatypeProperty and ObjectProperty. Was this needed? No, I don't think so. Did it happen regardless? Yes. So why should we block SHACL from the same benefits.

I will make no remark on opinions.

I do not intend to "block SHACL from the same benefits." I mean most to note that sh:ShapeClass subsuming rdfs:Class direct assertions sets up an intermediary phase before a certain threshold of adoption of SHACL 1.2, where extra support will be needed for some usage patterns to recognize a subclass hierarchy. My own use cases don't happen to be affected, because sh:ShapeClass specifically can't give the same syntactic sugar for owl:Class. But this may be a "Speed bump" of adoption. Or, the working-group may decide it's a sufficiently minor cost to require the early waves of sh:ShapeClass users to import sh:.

The owl:import is not needed but I think it's generally a reasonable expectation for RDF-based tools to look up ontological definitions. This is at the very heart of semantic web technology.

Overall while I acknowledge there can be corner cases where tools may have some limited understanding of sh:ShapeClass, I think the consequences of this pale in comparison to the benefits of having sh:ShapeClass generally available to everyone else, especially SHACL tools. A tool that doesn't know about SHACL wouldn't behave differently when it encounters a sh:ShapeClass anyway. SHACL is in the same category of languages as OWL and therefore has the same rights to introduce new terms.

Again, I do not intend to deny rights of growth. I just wish the working-group to remain aware that some forms of growth entail a cost for interoperability, borne by someone between working-group and end user (inclusive).
Subsuming a base structural class is, to me, a non-zero risk. But it's entirely possible that it's such a small risk, especially versus advantages in opened design, that the group finds it easy to accept. Getting to find out is one of the benefits of getting to work with such an experienced group, and I look forward to seeing how this goes.

[HolgerKnublauch]

@ajnelson-nist My apologies that I have put words into your mouth that you didn't state or mean to say. My mistake. I was over-interpreting what you wrote, but then I believe I was clear that it was just my interpretation via "you seem to say".

I don't know how to proceed here. We were supposed to make progress through Github discussions. We appear to have different opinions on the severity of any potential misinterpretation by tools that don't know about SHACL 1.2. Much of this is, of course, speculation and difficult to predict because it is about the future adoption of SHACL. I guess this topic needs input from other people of the WG.

[ajnelson-nist]

All's well, @HolgerKnublauch . I appreciate it.

I also agree, you and I are of differing opinion on how much of an issue this is---or possibly, whether it's an issue? I agree it's time for others' thoughts.

As this thread sits now, I'm fine with us having one settling discussion in a working-group call, if nobody else replies on the thread. I have a hunch it'd be around 5, at most 10, minutes of a call.

[PapoutsoglouE]

@ajnelson-nist I see where you are coming from with these concerns and I am glad that this has been brought up. It has sparked discourse about the evolution of SHACL that will likely become increasingly important as this WG advances.

Would it be help at all to approach this from an instructional perspective rather than a technical one? Perhaps with a note like "Be aware that using ShapeClass in SHACL-unaware implementations may pose XYZ risks."
That alongside Holger's suggestion:

What about we include an informal comment that explains that in order to be friendly to OWL, you should do X and Y (which could be "don't use rdfs:Class" and "use owl:Class instead"), so that you can live with the current proposal?

Of course, people who blindly import others' work may be affected if they overlook this small detail. But in such cases, that would probably be far from the biggest worry.

I will add this to the agenda and hope we can reach a decision on this point in the next WG call.

[ajnelson-nist]

@PapoutsoglouE I'm doubtful of the value of an instructional perspective. My thinking is that expecting a user to read documentation to adapt their system to SHACL 1.2 might not function well in the transitive case.

Say SHACL 1.2 in sh:ShapeClass-using graph A gets imported by B because B likes the class hierarchy but is indifferent to the shapes. Maybe the B architect reads the SHACL 1.2 documentation well enough to adapt their system to understand sh:ShapeClass---but just their system. Then what about a user of C that imports B?
The first transitive-adopter of A in this chain that doesn't supply the knowledge that "sh:ShapeClass implies rdfs:Class" sets up a problem for the first user that strictly requires rdfs:Class designations, whether on hard-coded triples or through a round of inferencing that includes at least subclass entailment.

I don't know how many users there are of systems that flag "undefined class" usage. That's the population that I think is affected by this risk, and there are other operational conditions I've enumerated above (particularly non-inferencing) that could make this syntactic sugar into a non-trivial workflow matter to remediate (setting up a step to mix in rdfs:Class "entailment" for all sh:ShapeClass instances). I'm not convinced documentation alone can prevent this matter.

Even as the working group considers whether their own userbases would be affected like I've described, I wish us to remain mindful of populations that could be.

[HolgerKnublauch]

I have added the following recommendation to the PR:

e4dd040

I believe this makes sense. By adding owl:imports of the sh: TTL graph, any tool with support for owl:imports should pull the missing triples in, and those will then also be applied to transitive use cases, following semantic web best practices.

Having said this, I am still curious what specific problems would happen for "undefined class" usage. If tools struggle with undeclared classes, they would, for example, also struggle to understand that skos:Concept is a class, or that skos:prefLabel is a subPropertyOf rdfs:label. And of course, the elephant in the room, owl:Class.

At some stage we need to assume that tools will need to look up ontological definitions before they consume random graphs.

[ajnelson-nist]

PR #254 was merged before the group had a chance to discuss this on a call. (Oh, and I see it was just reverted.)

The "instructional perspective" is currently implemented.

I still believe this should be discussed on Monday's call. I feel I've said most of what I want to say on this topic, aside from this last note:
SHACL is but one language built on RDF. It is equally fair to assume inference on structural classes like rdfs:Class will work for SHACL as it would for OWL or any other vocabulary that subclasses rdfs:Class. A tool that supports RDF isn't necessarily required to support other class-modeling vocabularies.

[caribouW3]

FWIW, it's not reverted yet, I only created a branch that would revert it.

[ajnelson-nist]

FWIW, it's not reverted yet, I only created a branch that would revert it.

My mistake, I just saw the little ping in the thread here and didn't look if it was in the gh-pages branch. Thanks for the correction.

[VladimirAlexiev]

@ajnelson-nist talks about "RDFS parser errors". But what is this? Can you refer to the RDFS spec about such a term, or describe which existing sem web tools return such errors?

He also writes about "without SHACL-awareness". All it takes to be "SHACL aware" is to import or directly load the sh ontology.

If your concerns were real then any ontology that subclasses rdfs:Class and then uses that subclass, would be invalid (cause breakage or "parsing errors")! I don't think that is the case.

[ajnelson-nist]

@VladimirAlexiev - I got asked on the WG call to write a small demonstration. To your question, I meant to describe instantation of an RDF model in memory after reading a document, e.g. turning <urn:example:A> a rdfs:Class . into Class(IRI("urn:example:A")). Hopefully my Manchester-esque shorthand makes sense there.

Re: @bergos 's request from today's call:

The short demonstration centers on something I've seen come up in multiple tools with a "Strict parsing" mode, which I've seen sometimes be opt-in versus a default "lax" mode, but not always. With apologies if this muddies things, I believe I shouldn't identify the tools, as some folks welcome sternness in a parser (I'm one such person), but some may see it as a criticism.

Take this graph serving as an all-in-one shapes, classes, and individuals graph, compact.ttl:

# Boilerplate
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#>
# Local
PREFIX ex: <http://example.org/ex/>

ex:A a sh:ShapeClass .

ex:a-1 a ex:A .

# ex:B not defined - intentional for the example, but maybe accidental in practice.
ex:a-2 a ex:B .

Take a strict parsing tool, strict_rdf_parse, that requires rdf:type triples have only defined classes in their object position.

IF strict_rdf_parse DOES understands that sh:ShapeClass entails rdfs:Class, then only ex:B gets reported as undefined.

IF strict_rdf_parse DOES NOT understands that sh:ShapeClass entails rdfs:Class, then both ex:A and ex:B get reported as undefined. Remediations are either:

1. Have the provider of compact.ttl add an import triple, like, <http://example.org/ex> owl:imports sh: ..
   1. This remediation suggestion was included in PR #212: Added sh:ShapeClass #254 .
2. Have the user side-load the sh: turtle file at the same time as compact.ttl to help understand sh:ShapeClass usage ; or
3. Have the user opt in to some client application adding a triple C a rdfs:Class . for each undefined class C reported.
   1. This option is effectively the "lax" parsing tool described above, that sees "S a C" and just infers "C is a class" for its in-memory model. This might not raise any notice about ex:B not being defined, or raise a missed notice if there are enough classes to obscure ex:B in longer logs.

PR #254 includes the suggested, most-upstream remediation for sh:ShapeClass adopters who actually encounter this issue. If nobody else expresses that this is a concern for them, I'm fine with #254 remaining merged as is or just getting further typo-review passes.

@HolgerKnublauch , after @PapoutsoglouE 's requested review deadline passes, would you mind cross-linking PR #254 here before closing this Issue? I'd do it, but I don't want to trigger an auto-close of the Issue.

[VladimirAlexiev]

• Which is that strict_rdf_parse tool?
• Feed it the sh ontology and it should be able to see what sh:ShapeClass means

[ajnelson-nist]

• Which is that strict_rdf_parse tool?

Sorry, but I believe I have to follow institutional rules which prevent me from naming such a tool.

• Feed it the sh ontology and it should be able to see what sh:ShapeClass means

Agreed. That's what I meant by remediation 2 ("side-loading").

[HolgerKnublauch]

@ajnelson-nist for your example:

1. Wouldn't the strict_rdf_parse tool also complain about ex:A a owl:Class (given that owl:Class rdfs:subClassOf rdfs:Class is not asserted)?
2. Wouldn't it also complain about ex:c-1 a skos:Concept (given that the SKOS Core namespace is not imported)?

[ajnelson-nist]

@ajnelson-nist for your example:

1. Wouldn't the strict_rdf_parse tool also complain about ex:A a owl:Class (given that owl:Class rdfs:subClassOf rdfs:Class is not asserted)?

Yes, if the tool was unaware of, and not supplied with, OWL.

3. Wouldn't it also complain about ex:c-1 a skos:Concept (given that the SKOS Core namespace is not imported)?

Yes, if the tool was unaware of, and not supplied with, SKOS.

[HolgerKnublauch]

Ok, given that our situation is not different from OWL, SKOS or any other ontology, my impression is that I can close this ticket unless I hear otherwise by Thursday. Please correct me if anyone disagrees. The branch was already merged (by accident).

[ajnelson-nist]

I have no objections to the ticket being closed Thursday. Just wanted to check, has there been enough editorial review against the PR that was merged?

[VladimirAlexiev]

@ajnelson-nist I checked your excellent work on Cybersecurity and as I'm not bound by institutional rules, I'll venture a guess you're talking about Robot :-)

I vote to close this issue and keep the PR merged. But for the future I'll heed the issue you posted about PR procedures.

[TallTed]

@ajnelson-nist —

Sorry, but I believe I have to follow institutional rules which prevent me from naming such a tool.

It would be helpful if you could check with your institutional compliance people, and confirm whether this institutional rule applies in the way you suggest.

If you can name that tool, others can reproduce your experimental results, and thereby (hopefully) determine whether there is an issue in the tool (which we can then report to its source), or in what's being submitted to the tool (which we can then revise, as I believe it's our data).

[ajnelson-nist]

@TallTed - I'm well aware of your points, but I already understand that I can't name tools in this situation. With apologies, this is the line I have to be wary of, and I know it is a challenge for external-to-institution folks I interact with and for the longer record. Here, I can only describe qualities, and any may feel free to note tools that happen to fit some or all of those qualities, but I can neither confirm nor deny whatever tools I may have been thinking of.

I suggest it will not be a good use of group energy to ask me further on this, and I ask for patience with the process I need to follow.

[TallTed]

@ajnelson-nist — OK. I was asking you to check because you said "I believe", which is rather softer than "I know" or "I have been informed". Your new comment indicates that you have checked, and you have been informed, so you know. I will sadly accept that.