Re: functions of rdfs:isDefinedBy

Am Do., 13. Okt. 2022 um 10:55 Uhr schrieb Christian Chiarcos <
christian.chiarcos@web.de>:

> 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.
>>
>
Sorry for distorting the context. "that" in Pat's statement refers to the
Turtle file underlying http://www.w3.org/2000/01/rdf-schema#isDefinedBy.


> [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
>