search

CredentialEngine / Schema-Development

Development of the vocabularies for the CTI models
14 stars 8 forks source link

Issues around the use of xsd:anyURI as a range type #819

Closed stuartasutton closed 2 years ago

stuartasutton commented 2 years ago

We have used xsd:anyURI frequently when our intention was to say that the range of a property could be any resource (i.e., rdfs:Resource) As Phil correctly notes in https://github.com/CredentialEngine/Schema-Development/issues/812#issuecomment-1055533131, xsd:anyURI is a datatype and not a class suitable as range. Elsewhere, Nate has said that making a change from xsd:anyURI would entail significant implementation changes within Credential Engine. We need to clarify exactly what would be entailed (i.e., substance behind Nate's assertion) in correcting this error.

siuc-nate commented 2 years ago

Basically we use xsd:anyURI to know when the value of something is a URL literal and should not be interpreted as "follow this to find a registry resource". It's a useful distinction both when rendering data and when doing things like indexing for our search API.

philbarker commented 2 years ago

Trouble is that the value is not a URL literal, it's not a literal at all.

Would it be hard to A. use rdfs:Resource and interpret it in the same way? Or, better, B. use the URI value to tell you whether it's pointing to the registry?

A is at least correct, B is using the right data for the decision you want to make.

siuc-nate commented 2 years ago

If all we're talking about is changing every instance of use of xsd:anyURI for rdfs:Resource instead, and nothing else changes, then we may be able to accommodate that. We'd need to go over it with the Registry team and the CaSS team first to see what it would impact/break/etc since both of those teams leverage our context file.

siuc-nate commented 2 years ago

Trouble is that the value is not a URL literal, it's not a literal at all.

{
"ceterms:subjectWebpage": "https://example.com/123"
}

I don't know what you'd call that if not a URL literal (and if not, then what is a URL literal?). A string, treated as a URL, rendered as an HTML link, etc. Processing stops when it hits this item, as the link is not followed or resolved at all because the intent is to communicate the URL itself. That's why we went with xsd:anyURI, which as Stuart points out, is a data type - because it is the data type of the data we intended to communicate.

philbarker commented 2 years ago

I don't know what you'd call that if not a URL literal.

I'd call it the identifier of a webpage. If we were being nice to people using the data we would say that the range of subjectWebpage is a schema:WebPage, but we are in a place where we cannot be so nice so we just tell them that it's the identifier of something and let figure out what when they get there.

Processing stops when it hits this item,...

That's registry policy, which is fine, but we don't want to limit CTDL by registry policy.

what is a URL literal?

Something that is useful in XML (which is where it came from), not so useful in RDF.

stuartasutton commented 2 years ago

Coming out of this discussion, these uses of xsd:anyURI should be changed to rdfs:Resource.

What are the implications (registry/CaSS)?

siuc-nate commented 2 years ago

Anywhere their code is using xsd:anyURI, change it to use rdfs:Resource (but otherwise the functionality is identical). This would apply to wherever our systems are using it too.

Again: Is this applicable to every/all instances of our use of xsd:anyURI or would we end up having both xsd:anyURI and rdfs:Resource in our stuff?

philbarker commented 2 years ago

Again: Is this applicable to every/all instances of our use of xsd:anyURI or would we end up having both xsd:anyURI and rdfs:Resource in our stuff?

"All things described by RDF are called resources, and are instances of the class rdfs:Resource. This is the class of everything. All other classes are subclasses of this class." https://www.w3.org/TR/rdf-schema/#ch_resource

Attached is the list of terms with the range xsd:anyURI. Their ranges are all included under the heading of "everything" :-) (Seriously, I have checked, there is no problem.)

query-result (1).csv

jeannekitchens commented 2 years ago

@siuc-nate provide a final summary of exactly what the proposed changes are, their impacts and exactly what changes would be required by CaSS and Credential Registry.

siuc-nate commented 2 years ago

As I understand it, the intent would be to change any reference to a range of xsd:anyURI to instead use rdfs:Resource, but otherwise, the functionality would all be the same.

@stuartasutton @philbarker is that correct?

philbarker commented 2 years ago

Duplicate of #822