Invalid Reference of Shapes-Graph(?)

[hoijui]

shacl/shacl-core/shacl.ttl

Line 29 in 67459ed

sh:suggestedShapesGraph <http://www.w3.org/ns/shacl-shacl#> .

shacl.ttl:

sh:
	# ...
	sh:suggestedShapesGraph <http://www.w3.org/ns/shacl-shacl#> .

should rather be one of these (probably the former):

sh:
	# ...
	sh:suggestedShapesGraph <http://www.w3.org/ns/shacl-shacl> .
	# or
	sh:suggestedShapesGraph "http://www.w3.org/ns/shacl-shacl#"^^xsd:anyURI .

because <http://www.w3.org/ns/shacl-shacl#> can not be split into a prefix and an term-name unambiguously, and is thus not a valid RDF Term, or at least there are parsers that treat it this way.

I think the first (by me preferred) solution would also require the sh:line to change to <>, plus the inclusion of this line:

@base <http://www.w3.org/ns/shacl> .

and the same procedure in shacl-shacl.ttl.

Alternative solution

instead of sh: use sh:Ontology, and do the same for shsh: (-> shsh:Ontology).
That makes things easier to understand, and does not rely on parsers implementing the edge-case of an empty "postfix".
There are parsers that fail because of this.

[VladimirAlexiev]

Empty local names and empty prefixes are perfectly legal, just like you used an empty local name (<>) with a defined base.
So:

• sh: is a valid URL that expands to <http://www.w3.org/ns/shacl#>
• <http://www.w3.org/ns/shacl-shacl#> is also a valid URL
• : is a valid prefix that many ontologies use so they can write :term instead of ont:term (but I dislike such practice)

@HolgerKnublauch used this, which equates the ontology URL to its prefix. I also prefer this approach:

@prefix sh:   <http://www.w3.org/ns/shacl#> .
sh: a owl:Ontology

Other people would be shy and omit the # from the ontology URL, don't know why

@prefix sh:   <http://www.w3.org/ns/shacl#> .
sh: a owl:Ontology <http://www.w3.org/ns/shacl>.

The only "enhancement" I would do is define a second prefix, and then state

sh: sh:suggestedShapesGraph shsh: 

---

Now @hoijui let's turn to your concerns:

There are parsers that fail because of this.

Which are they? They are non-conformant

sh:Ontology, and shsh:Ontology

Why? Allocating hierarchical URLs is a great practice, see https://patterns.dataincubator.org/book/hierarchical-uris.html. So:

• sh: is the ontology
• sh:NodeShape is a class within it
• etc

That makes things easier to understand,

Given that you seem to understand <>, I don't see why you should be puzzled by what sh: means.

But here's a puzzle for your enjoyment: what is ?x (<>|!<>)+ ?y in SPARQL?

[hoijui]

Thank you @VladimirAlexiev !
I see it now.. indeed makes more sense to not use bla:Ontology.
The separator "yes|no" is still an open question to me thought.

Use separator in ontology IRI?

pro

One argument could be, that if it is left out, one can not deduce from the ontology IRI alone, whether the terms will be available with # or with / as the separator.

contra

When browsing, I get served HTML. A simple page is usually located at a URL like these:

https://github.com/w3c/shacl/
https://github.com/w3c/shacl.html

Having a # at the end there would be quite extra ordinary.
This to me is like the ontology.

The # is then the separator between the page and the part of the page (usually a heading) This page#heading - to me - is the direct analog to ontology#term. The # is the delimiter, and having it without the two parts being present only makes sense for the prefix. As best practice also promotes hosting the URL as HTML, this translates directly.

I lean towards the contra argument.

[TallTed]

The # is the fragment delimiter, and it is not typically sent by a browser to the server.

The browser requests a resource with the URI up to but not including that delimiter. The delimiter and the fragment identifier that follows are used by the browser to locate the fragment within the resource representation delivered by the resource server.

This is distinct from discussion of prefixes and prefixed names.

A prefixed name is turned into a full URI before the browser makes a resource request. The server never knows anything about the prefix declaration nor the prefixed name.

[VladimirAlexiev]

@hoijui There are well accepted "slash vs hash" guidelines, which stem from the fact that a client doesn't send the fragment to the server:

• Use hash for small namespaces where it makes sense to return all terms defined there, at once
• Use slash for bigger collections of things

Please close the issue?