Re: functions of rdfs:isDefinedBy

On Thu, Oct 13, 2022 at 9:55 AM Christian Chiarcos <
christian.chiarcos@web.de> wrote:

> 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] 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)...?


>
>
>> [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} Ok, fair enough. It does make me wonder what's the value of stating
that *anything* has a range of 'rdfs:Resource' then (i.e., if the
interpretation of something belonging to the Class of 'rdfs:Resource' is
"An RDF thing, or not an RDF thing - basically anything at all". How is
that more valuable (i.e., worth stating) than not providing an 'rdfs:range'
triple at all?). I'd be interested to hear what other people might think.


>
>
>> [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).
>
> [PMcB] Yeah, fair enough. That was just a spitballing suggestion really...


[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?
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 (as an individual vocab term is just a 'resource' in my
mind) - i.e., it seems intended to precisely support our purpose here. It
can be used to support many other purposes I'm sure too (I've no problem
with that), but to me it still seems perfectly fit for our purposes here.


[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.
>
>
Yeah perfect - thanks so much for doing that!


> Best,
> Christian
>

-- 
This e-mail, and any attachments thereto, is intended only for use by the 
addressee(s) named herein and may contain legally privileged, confidential 
and/or proprietary information. If you are not the intended recipient of 
this e-mail (or the person responsible for delivering this document to the 
intended recipient), please do not disseminate, distribute, print or copy 
this e-mail, or any attachment thereto. If you have received this e-mail in 
error, please respond to the individual sending the message, and 
permanently delete the email.