Proposal: add a "description" rel value #1666
Comments
|
Do we need to mint another description value when you can already do: (or even Ideally, we're supposed to keep bare name rel values compatible the IANA and HTML link relations. Neither currently defines a description value. HTML has a DCTERMS.description proposed value, but I think in our case it would be better to keep the prefixed version. |
|
Pragmatically, you are right, and maybe that is what we should do. My reticence comes from my semantic web influence, I guess: if I look at the meta and link elements and (informally, I know) translate them to proper triple statements, then what I get is that the statement with a property But I acknowledge that this is a theoretical purity issue; if everyone is fine with this approach, I am happy to settle on this. |
But isn't this what you're supposed to be doing with dcterms linked metadata? The expected type is property, not literal text. I know they've relaxed their rules/expectations to allow text values all for the properties, but most are supposed to be links. But even if we mint another description term, we're still going to end up with a triple whose value is a URL, no? I'm fine adding an example to the spec if we want to acknowledge that you can use link for individual properties in another format and not just full records. |
|
Heh. I did not realize that DCMI side-stepped this issue. I looked into the dcterms RDF definition, which also defined
but there is no Bottom line: using But adding an example that covers the original use case would actually be a good idea. I am happy to put in a PR on this on Monday, unless you beat me into it... |
More precisely: add a "description" term to the Link Relationships Vocabulary.
This would make it possible to use the Link Element to refer to an extended description with a specific media type (e.g., HTML, Markdown...).
For the origin of the use case see: #1650, the proposed solution in #1650 (comment).
(Note, the WG resolution is not to accept the proposal as it was originally raised in #1650, this would be a replacement.)
The text was updated successfully, but these errors were encountered: