Repository navigation
Proposal: add a "description" rel value #1666
Description
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.)
Activity
mattgarrish commentedon May 7, 2021
Do we need to mint another description value when you can already do:
(or even
rel="dc:description"orrel="schema:description"?)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.
iherman commentedon May 8, 2021
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
dc:descriptionhas a value of a URI and not a text which, I believe, is not in line with the DCMI specification.But I acknowledge that this is a theoretical purity issue; if everyone is fine with this approach, I am happy to settle on this.
mattgarrish commentedon May 8, 2021
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.
iherman commentedon May 8, 2021
Heh. I did not realize that DCMI side-stepped this issue. I looked into the dcterms RDF definition, which also defined
dc:descriptionas an (RDF) subproperty ofdc:descriptionin the dc RDF defintion and, in both cases, all it says for the description (sic!) ofdescriptionis:but there is no
rdfs:rangethat would say the value is supposed to be a literal (which I expected would be the case). Ie, I was wrong in believing that we would be violating usingdc:descriptionas the property of a<link>element because we do require the value to be a URL.Bottom line: using
dc:descriptionis indeed a good approach and solves the original use case and this issue is rubbish :-)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...