Re: functions of rdfs:isDefinedBy

>
> [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] That's a good reference, and yeah, fair enough - it's left pretty
> open to interpretation (by design I'm sure).
>
> But that same reference also explicitly says: "This property may be used
> to indicate an RDF vocabulary in which a resource is described." I think
> that's very unambiguous. And doesn't that sentence fit perfectly the use
> case we're talking about here (i.e., individual vocab terms linking back to
> the vocab that describes them)...?
>

It does -- but it uses *may*, so this is one possible application only. And
if I'm right about the function of rdfs:isDefinedBy to be intended vehicle
of adding external (and esp., non-RDF) semantics to RDF data, it must not
be reduced to this application.


> [PMcB] So that is clearly communicating that the 'rdfs:range' should be
>>> RDF.
>>>
>>
> [PMcB} Ok, fair enough. It does make me wonder what's the value of stating
> that *anything* has a range of 'rdfs:Resource' then
>

[CC] This is the RDF 1.0 way of saying "not a Literal". Since the
introduction of rdfs:Literal, this is pointless, indeed.


> [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] I don't really follow the above two paragraphs - but when you say
"*Re-purposing* rdfs:isDefinedBy for vocabulary resolution...", are you
saying that you think using 'rdfs:isDefinedBy' to point from an individual
vocab term to the vocabulary that defines it is re-purposing that it?

[CC] Yes, because this leads to a much narrower interpretation that rules
out one of the intended use cases. (I presume logical formalization and
their semantic [in]completeness was a concern in the early RDFS days.) I
mean if that was supposed to be the primary function, why doesn't the spec
have "should" in place of "may"? And it creates a gap in the RDF ecosystem,
the ability to integrate authoritative external (RDF or non-RDF)
definitions into an RDF vocabulary.  If there is no better existing
property, creating a designated sub-property of rdfs:isDefinedBy to point
to the vocabulary as a whole would be a better way to go. (But I actually
think there is, see below.)

> [PMcB] Because I think your reference above stating "This property may be
used to indicate an RDF vocabulary in which a resource is described" seems
like a perfect fit to me

[CC] Yes ... but then, it doesn't imply that the vocabulary is the same
vocabulary as the one that your own term belongs to. It could (and -- as I
interpreted that originally -- it should) refer to another vocabulary from
where the definition of a term is imported. IMHO, the suggested
self-reference would be a borderline case of the intended function because
-- you guessed it ;) -- conventional hash URIs provide that information
already.

[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.
>>
>
[CC] I'm all for dct:isPartOf ("A related resource in which the described
resource is physically or logically included."). Along with its inverse
dct:hasPart, it is used in this very function in DCAT (
https://www.w3.org/TR/vocab-dcat-3). Note that (unlike rdfs:isDefinedBy)
this definition has nothing to do with semantics whatsoever -- and your use
case doesn't require that. But it actually asserts that the dataset
(vocabulary) is identical to the vocabulary that your source term comes
from, whereas rdfs:isDefinedBy doesn't do that. So, that's a much better
fit and an established metadate property.

Best,
Christian