functions of rdfs:isDefinedBy

Dear Pat, dear all,

this sprung off from the earlier discussion of Slash URIs in "Re: (Lost in
the noise perhaps - so asking again) - Is a trailing slash 'better' than a
trailing hash for vocabs namespace IRIs?]".

For vocabularies using Slash URIs, there is need for a standard property to
point from a (TBox) concept to the URI from where to retrieve a full
representation. Pat suggested rdfs:isDefinedBy. I agree on the need and the
need for a wider agreement, but think we should use or create a different
property for the purpose.


> [PMcB] I wouldn't really mind which predicate becomes the Best Practice -
> I just like 'rdfs:isDefinedBy' because it feels so intuitive, and it exists
> in one of the 'core' RDF vocabs already (and it seems to be the most
> commonly used in practice - not that that's a particularly strong
> justification!)
>
> [PMcB] But I'd still suggest that your use of 'rdfs:isDefinedBy' to point
> to the URIs of *unstructured documents* might not be strictly correct. I
> mean, here's the actual complete definition of that term (complete with
> typo in the value of the 'rdfs:comment' triple :) !): ...
>

[CC] Hm, I always took the *text* of the W3C specification to take priority
over the RDF spec (simply because that couldn't capture the full semantics
anyway), and https://www.w3.org/TR/rdf-schema/#ch_isdefinedby clearly says
*twice* that "the resource O defines S" [as an unstructured text can] and
more specifically that while "[i]t may be possible to retrieve
representations of O from the Web, (...) *this is not required*. When such
representations may be retrieved, *no constraints are placed on the format
of those representations*." (emphasis mine)


> [PMcB] So that is clearly communicating that the 'rdfs:range' should be
> RDF.
>

[CC] Actually, not really. https://www.w3.org/TR/rdf-schema/#ch_resource:
"All things described by RDF are called *resources*, and are instances of
the class rdfs:Resource. This is the class of everything." This doesn't
mean that the object URI has to resolve to an RDF representation (it's
clear that we would want that but this is not part of the RDF(S) spec at
all, but of that of Linked Data). This only means that RDF can be used to
provide information about that URI (which we do by using this as subject,
object or predicate in any triples -- irrespectively of that this URI
resolves to, if at all). And as quoted above, the definition underlines
this very explicitly for this particular case.


> [PMcB] 'prov_o:wasDerivedFrom' (but that has the range 'prov_o:Entity').
> ...  'dcterms:source' ... seems to fit your use case pretty well to me -
> i.e., "This property is intended to be used with non-literal values. The
> described resource may be derived from the related resource in whole or in
> part. Best practice is to identify the related resource by means of a URI
> or a string conforming to a formal identification system.".
>

[CC] My issue with dct:source (and prov_o:wasDerivedFrom) is the notion of
"derivation". Derivation involves (and, depending on context, requires)
modification (either an interpretative action or a rule-based
transformation), and this can be anything up to something as  vague as
"giving inspiration to". But rdfs:isDefinedBy is much more concrete,
because it tells us where to find the definition that holds for S, i.e.,
that the exact semantics of the subject term are provided by the
(information associated with the) object URI, regardless of formalism used
for providing that definition (and yes, plain text can do that, as well).

[CC] And it is pretty clear why such a property is necessary in the wider
context of RDF and the Semantic Web, because we knew from the beginning
that formal semantics would never be able to cover everything (by Gödel's
incompleteness theorem). In consequence, there must be a standard way to
complement RDF semantics with external semantics. This is the primary role
of rdfs:isDefinedBy -- and I don't see how this function could be served by
anything else. And also, this is why this functionality is needed at the
very core of RDF.

[CC] Re-purposing rdfs:isDefinedBy for vocabulary resolution is not
strictly speaking wrong. In fact, for cases where RDF semantics are
sufficient, this is among the intended functions, I guess -- but if we aim
for the complete formalization of *anything* with RDF or any technology
building on RDF, it *must never* be limited to this function. Yet, if such
a best practice would be generally followed, it could amount to exactly
that. On the other hand, Prov-O, DCAT and Dublin Core are specifically
designed to deal with resource metadata, and by all means, information
about technical aspects of the hosting of documentation is not metadata and
should be dealt with in that context.

[PMcB] Anyways, I'd certainly be open to suggestions for a different/better
> predicate to use as Best Practice guidance for linking a vocab term back to
> its defining/containing/describing vocab. But that would be a separate
> issue/thread though!
>

I guess so ;) I just gave it a new subject.

Best,
Christian