Registration Request: conformsto

[hoehrmann]

Relation Name

conformsto

Description

Refers to an established standard to which the link's context conforms to.

Reference

http://purl.org/dc/terms/conformsTo

Additional Information

No response

[mnot]

Have you discussed this registration with Dublin Core?

Keep in mind that there are already well-known URLs for DC terms.

[hoehrmann]

The term has been defined since 2001 and predates the registry by over nine years. There is no doubt the DC relations are intended to be used in web linking (take https://www.dublincore.org/specifications/dublin-core/dcq-html/2003-11-30/ and its successor for instance) and they are used like that (https://www.w3.org/TR/epub-a11y/#example-expressing-conformance-to-an-optimization-standard for instance).

Using the full URI is in this case at odds with the requirement to use all-lowercase URIs for extension relations, and it is also very inconvenient, especially in contexts without a namespacing mechanism, and in some cases is not even an option for formats that predate RFC 5988 and/or do not allow using URIs.

The registry is now over 13 years old and nobody has registered this over 22 years old term. I could contact Dublin Core about this, but I do not really have an idea what to write them, and I also do not see what the outcome should be, or how a registration request would be any different from this one.

I have sent a pointer to this issue to their contact address with an invitation to join the discussion here if there are concerns or objections.

[mnot]

It may well be that they were designed with that intent, but the specification needs to be specifically about registering values within the framework defined in the RFC. I'll close this, as it really should be opened by DC if they're interested.

[tombaker]

@mnot @hoehrmann I am co-Chair of the DCMI Usage Board (standards committee) together with @niklasl and am happy to answer any questions you may have.

I'm not sure I understand the issue at hand. The official URI for conformsTo is indeed http://purl.org/dc/terms/conformsTo and we are happy to see it used wherever it may be useful, eg in https://www.w3.org/TR/epub-a11y/#example-expressing-conformance-to-an-optimization-standard . If you want to include it in a list, or registry, of relation properties (if that is the issue), we are happy and can confirm that you do not actually need our permission to do this. Please let me know if you have any questions.

[hoehrmann]

@tombaker Thanks for chiming in. My goal here: when I say rel="conformsTo" in some web linking context I want recipients of such a message to be able to go to https://www.iana.org/assignments/link-relations/link-relations.xhtml and learn that conformsTo is a convenient shorthand for http://purl.org/dc/terms/conformsTo and thereby also promote reuse of this link relation by other applications. That is the purpose of this registry according to https://www.rfc-editor.org/rfc/rfc8288.html#section-2.1.1 and as I understand you, the DCMI would pretty much welcome such an addition to the registry.

@mnot has, as I understand it, rejected my request because the Dublin Core standard does not reference the RFC he authored, despite his earlier stance to the contrary (https://mailarchive.ietf.org/arch/msg/link-relations/ssWbDqmYQ3tb-b8xWxxEnXoqu-s/, or take all the HTML relations as another example) and because it was me who asked for this convenience, rather than the DCMI. Since Mark »should be strongly biased towards approving registrations« and »relation types can be registered by third parties« according to the RFC, I think Mark has failed to clearly identify the issues that caused refusal of this registration request.

[mnot]

The immediate issue is that @hoehrmann is attempting to register a value as a third party using a reference to something that is not explicitly defined as a link relation within the meaning of RFC8288. Registration by a third party has requirements which are not cited above:

relation types can be registered by third parties (including the expert(s)), if the expert(s) determines that an unregistered relation type is widely deployed and not likely to be registered in a timely manner otherwise.

I have not made a determination regarding either of those criteria yet.

Normally, it is preferable for the community that wrote and has change control over a specification to make the registration request; the third-party clause in 8288 is designed for cases when that isn't possible, which doesn't appear to be happening here.

@tombaker if there's interest from the DCMI in registering DC terms as relation types, we can facilitate a request. However, it's important for you to understand what effects that would have.

Registering a link relation implies that the entry is usable within the framework described by RFC8288, which includes (but is not limited to) use in the Link HTTP header field and the Atom syndication format. As I alluded to above, RFC 8288 already allows URIs to be used to identify relation types, so DC is already usable within that framework. @hoehrmann is effectively asking for registration of a 'shortcut' or 'convenience' name to use with a DC term instead of the full URI that you've pointed out.

Additionally, some serialisation formats define URIs for registered relation types, which effectively creates an alias for the existing URI. For example, in the Atom syndication format it would be valid to use the URI http://www.iana.org/assignments/relation/conformsto to refer to http://purl.org/dc/terms/conformsTo. That may or may not be desirable.

If the DCMI wishes to proceed, I'd suggest that you register of all relevant DC terms (e.g., all sub properties of Relation) together instead of doing it piecemeal. Although link relation types are case-insensitive, you may want to carefully consider the registered case, since the URL serialisation in Atom uses the registry casing. It would also necessary to identify any clashes with already-registered terms and decide what to do if any are found.

Because of the complexity of doing so for all of Dublin Core, I'd recommend drafting a short document to request the registrations, rather than doing it ad hoc in this repository. However, I'm open to discussion if that's too onerous.

[hoehrmann]

Using the DCMI definitions with s/described resource/described resource (context)/ because the registry does not talk about described resources anywhere else, that would look like this.

Relation Name	Description	Reference	Additional Information
conformsto	An established standard to which the described resource (context) conforms.	^1	Shorthand for http://purl.org/dc/terms/conformsTo
hasformat	A related resource that is substantially the same as the pre-existing described resource (context), but in another format.	^1	Shorthand for http://purl.org/dc/terms/hasFormat
haspart	A related resource that is included either physically or logically in the described resource (context).	^1	Shorthand for http://purl.org/dc/terms/hasPart
hasversion	A related resource that is a version, edition, or adaptation of the described resource (context).	^1	Shorthand for http://purl.org/dc/terms/hasVersion
isformatof	A pre-existing related resource that is substantially the same as the described resource (context), but in another format.	^1	Shorthand for http://purl.org/dc/terms/isFormatOf
ispartof	A related resource in which the described resource (context) is physically or logically included.	^1	Shorthand for http://purl.org/dc/terms/isPartOf
isreferencedby	A related resource that references, cites, or otherwise points to the described resource (context).	^1	Shorthand for http://purl.org/dc/terms/isReferencedBy
isreplacedby	A related resource that supplants, displaces, or supersedes the described resource (context).	^1	Shorthand for http://purl.org/dc/terms/isReplacedBy
isrequiredby	A related resource that requires the described resource (context) to support its function, delivery, or coherence.	^1	Shorthand for http://purl.org/dc/terms/isRequiredBy
isversionof	A related resource of which the described resource (context) is a version, edition, or adaptation.	^1	Shorthand for http://purl.org/dc/terms/isVersionOf
references	A related resource that is referenced, cited, or otherwise pointed to by the described resource (context).	^1	Shorthand for http://purl.org/dc/terms/references
replaces	A related resource that is supplanted, displaced, or superseded by the described resource (context).	^1	Shorthand for http://purl.org/dc/terms/replaces
requires	A related resource that is required by the described resource (context) to support its function, delivery, or coherence.	^1	Shorthand for http://purl.org/dc/terms/requires
source	A related resource from which the described resource (context) is derived	^1	Shorthand for http://purl.org/dc/terms/source

[hoehrmann]

@mnot

Although link relation types are case-insensitive, you may want to carefully consider the registered case, since the URL serialisation in Atom uses the registry casing. It would also necessary to identify any clashes with already-registered terms and decide what to do if any are found.

There are no clashes with registered relations and the casing is covered by https://www.rfc-editor.org/rfc/rfc8288.html#section-6 which requires all-lowercase names in the registry.

[evert]

I know this is a closed issue, but if these proposed relationship types are all short-hands for a canonical definition starting with http://purl.org/dc/terms/, why is registration desired at all? Given that relationship types can be URIs, wouldn't it make more sense to use the canonical/expanded DC terms. Registration is not required for those either.

[hoehrmann]

I know this is a closed issue, but if these proposed relationship types are all short-hands for a canonical definition starting with http://purl.org/dc/terms/, why is registration desired at all? Given that relationship types can be URIs, wouldn't it make more sense to use the canonical/expanded DC terms. Registration is not required for those either.

We've covered this in this thread already. RFC 8288 introduces the concept of registered relation types by saying »Well-defined relation types can be registered as tokens for convenience and/or to promote reuse by other applications«. Furthermore, it says »all-lowercase URIs SHOULD be used for extension relations.« And not all contexts that make use of link relations actually allow using URIs, or make it difficult beyond having to memorize and type out long strings, like having to apply special escaping rules.

I could just use tag:example.org,2024,conformsto but then I would probably be the only one using that. I do not know, have no way to find out, what others might be using, or what might actually be implemented by agents like catalog systems or search engines. We have a registry to address problems such as these.