syntax-rule-prefixes-duplicates should be more lenient

[VladimirAlexiev]

https://w3c.github.io/data-shapes/shacl/#syntax-rule-prefixes-duplicates

If ... prefix declarations contains multiple namespaces for the same value of sh:prefix, then the shapes graph is ill-formed.

I think this should be changed to "multiple different namespaces".

Rationale: this will facilitate more flexible management of imports. Scenario:

• shape "module (ontology) A declares prefix x:
• now you discover shape "module" B that has useful shapes, so in A you do import B
• but it happens that B also declares prefix x:: that would not be unusual, if A and B talk of related domains!
• now A is invalid. You need to fish out the duplicated prefix x: and remove it from A
• if later you decide that import B was not so useful after all, you need to put the prefix back in

To summarize: the rule requires each prefix to be declared exactly once in any collection of related shapes that may want to include one another.
That makes module refactoring harder than it needs to be.

---

In other languages:

• SPARQL Are prefixes carried from one section to another? Can they repeat? sparql-update#54
• Turtle forbid redefining the same PREFIX; consider forbidding relative BASE rdf-turtle#87

[HolgerKnublauch]

I don't see how this can be implemented. We cannot just add the word "different" and be done with it.

If there are two namespaces for the same prefix, which one should the engine use?

[ajnelson-nist]

I've noticed sh:prefix is a rather powerful mechanism for what it imposes on importers.

It's also a potential friction point if, complementing @VladimirAlexiev 's example, there are TWO useful shape sets.

Suppose there is a shapes graph A that wants to import shapes graphs B and C. But, both declare a prefix x: with different expanded values. If B and C are outside of A's ability to modify, A's stuck either choosing just one, or distilling what it wants out of both by deleting parts in an adapted copy or duplicated implementation. Either way, the total value provided by B and C is diminished.

Offhandedly, I suspect the situation has an equally dissatisfactory feel if A sets a prefix x:, imports B, and B happens to import C which sets a conflicting prefix x:.

Fundamentally, I think the transitive nature of owl:imports has a tension with sh:prefix. I think alleviating this would require a specification change. I have a couple examples on what that change could be, but my hunch is that neither will work, so I'm not sure of a "Happy" resolution.

As an example, which I'll put forward to point out a glaring issue:
The "inheritance" of prefix declarations from anything imported could be changed to be an opt-in or opt-out mechanism, versus today where there is only the default of everything imported applies. The issue with this is a conflict with the nature of owl:imports: Everything's brought in from the imported graph, and treated like it's in the importing graph. Hence, an alternative mechanism sh:imports would need to be defined to tweak behaviors of specifically sh:declares, and I feel that's an overreaction versus the scale of this issue.

As another example, which I think is a bit more plausible but will probably be quick to foil once spelled out in demonstration data:
The scope of sh:prefix could be re-defined to JUST be the owl:Ontology it is declared against, and ONLY be usable for shapes "within that namespace." This might make a new grade of imposition, though - "Within that namespace" could loosely be interpreted two ways.

1. The shape or constraint would need to start with the IRI of the owl:Ontology.
   1. Specifying this logic will likely get messy with various shape and constraint sharing strategies (sh:node, sh:sparql, letting sh:SPARQLConstraint be a blank node).
   2. And, this will butt heads with the current freedom in SHACL to have shapes in a graph named with IRIs that have nothing to do with the IRI of the owl:Ontology at the top of the shapes graph.
2. OR, the shape or constraint must be within "the graph" bearing the owl:Ontology.
   1. Once "the graph" is not nicely contained within a file, this could also be tricky to understand.

I get the feeling some worked-out demonstration graphs will make this line of thought crumble as well.

Before sketching those demonstrations, we should consider if this tension between owl:imports and sh:prefix is something that should be addressed.

I see it as a concern that a convenience element for SPARQL queries can induce an incompatibility hindering interoperability and reuse.

[HolgerKnublauch]

Thankfully, each SPARQL query in SHACL can point to a different subject using sh:prefixes, and that subject does not have to be the owl:Ontology with owl:imports. Therefore I don't really see a problem even if the owl:imports closure contains the same prefix twice.

I think this issue should be closed.

[ajnelson-nist]

I think there is a concern here. I will try to add a test in a PR to see if our points align. Apologies if I don't get to the test today.

[VladimirAlexiev]

hi @HolgerKnublauch !

If there are two namespaces for the same prefix, which one should the engine use?

It should return an error

I don't really see a problem even if the owl:imports closure contains the same prefix twice.

Me neither. That's exactly what I'm asking: to clarify the wording by adding the word "different".

[HolgerKnublauch]

Ah Ok I see. There could indeed be multiple declarations of the same prefix/namespace combination. Will create a PR.