Re: (Lost in the noise perhaps - so asking again) - Is a trailing slash 'better' than a trailing hash for vocabs namespace IRIs?

> [PMcB] Well, as I stated in my response to Pierre-Antoine, I consider it a
> fundamental principle of Linked Data that you can never fully know the
> 'intended use case' for any shared vocabulary - as literally anyone should
> be able to reuse that vocab, even within the confines of a closed
> Enterprise (e.g., via mergers or acquisitions in the future).
>

True, but the creator of a vocabulary typically does. For vocabularies
whose usage of slash or hash really presents a problem, natural selection
will kick in in the end. But I actually think this is a minor concern.


>   the other Best Practice of providing `rdfs:isDefinedBy` triples per
> term.
>

I actually have a bit of an issue with this as a best practice, because it
doesn't have to refer to the full RDF vocabulary. It may be used for this
purpose, but in fact, I've been frequently using it to link concepts with
the URIs of the *unstructured documents* that define them. And these are
unstructured because there just is no normative RDF vocabulary for that
particular domain. Think of language identifiers. ISO 639-1 and -2 are
available as RDF, but ISO 639-3 is not, so the normative reference for any
language not covered by ISO 639-1 or -2 is a bunch of human-readable tables
on a website, and if I wanted to provide the "is defined by" context of,
say my:EgyptianArabic, that would not be the my:-ontology, but
https://iso639-3.sil.org/code/arz. I don't think there is another RDF(S)
property to serve that purpose (not within the RDF[S] namespace, but we
could go with dc:source, but that has somewhat different semantics;
similarly, owl:sameAs would be wrong because it comes without an RDF
formalization, and we cannot really be sure whether
https://iso639-3.sil.org/code/arz is meant to be a class or an instance,
whereas my:EgyptianArabic if it is proper OWL2/DL, should be one or the
other).

If we make *that* a best practice recommendation, we should also propose
another property for the other use case (pointing to the defining resource
if it is not an RDF vocabulary).


> If a vocabulary provider relies massively on OWL2 inferences to
>> pre-populate the ontology with, say, static values for properties of
>> individuals of a particular type, then these will not be found (or need to
>> be explicitly searched for) if only the local URI and its immediate context
>> is returned. In other words, defaulting to shlashes might be a possible
>> strategy for ontologies *only if they don't make use of implicit triples*.
>>
>
> [PMcB] I might be missing something here, but would simply dereferencing
> the vocab namespace IRI not solve this issue?
>

Yes.


> In other words, if this community came to agreement on the Best Practices
> of [use-slashes + provide-`rdfs:isDefinedBy`-triple-per-term +
> dereferencing-vocab-namespace-IRI-gives-full-vocab-metadata], then vocabs
> that followed that Best Practice wouldn't have any problem here - client's
> could just dereference the namespace IRI and get everything they need in a
> single server repsonse, right?
>

Yes -- if we agree on that best practice ... not 100% sure we will, mostly
because the semantics of rdfs:isDefinedBy are actually broader than this
use case. This is one use case it covers, and it is mentioned as such
("may") in the spec, but it is not the only one.

The alternative thing to do would be to create/resort to a designated
property to provide the full vocab. That could be dct:isPartOf ("A related
resource in which the described resource is physically or logically
included.") Wrt. a best practice for pointing to the containing vocabulary,
I would prefer that over rdfs:isDefinedBy, and it's already an established
property from an established vocabulary.

But I'm all for a best practice recommendation of that kind for slash URIs.

Best,
Christian