Open hoijui opened 1 month ago
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
, andshsh:Ontology
Why? Allocating hierarchical URLs is a great practice, see https://patterns.dataincubator.org/book/hierarchical-uris.html. So:
sh:
is the ontologysh:NodeShape
is a class within itThat 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?
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.
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.
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.
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.
@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:
Please close the issue?
https://github.com/w3c/shacl/blob/67459ed023305fdd63d35f25bd422045d77425fb/shacl-core/shacl.ttl#L29
shacl.ttl:
should rather be one of these (probably the former):
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:and the same procedure in shacl-shacl.ttl.
Alternative solution
instead of
sh:
usesh:Ontology
, and do the same forshsh:
(->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.