- From: Andrea Rendine <master.skywalker.88@gmail.com>
- Date: Sun, 15 Mar 2015 15:07:09 +0100
- To: "public-html@w3.org LIST" <public-html@w3.org>, whatwg@whatwg.org
- Message-ID: <CAGxST9mn=Ar=dxedru0KLA-o64ERJ9q3raGjoi+79kwFaWchWQ@mail.gmail.com>
More than one year ago I first updated the page MetaExtension on WHATWG wiki, in order to introduce values for @name according to DCMI "dc-html" documentation (http://dublincore.org/documents/dc-html/). There are several mistakes in the dc. and dcterms. list as of now, I tried to fix them, but my edit was reverted because items cannot be removed that easily. So I will submit my edit request here and wait for approval. Changes to make: - The properties dc.created, dc.date.issued, dc.dateCopyrighted, dc.dateSubmitted, dc.license, dc.mediator, dc.medium, dc.modified, dc.provenance, dc.references, dc.temporal, dc.valid are to be REMOVED because not defined by the specification. dc.prefixed properties can be associated to both /terms/ and /elements/1.1/ Dublin Core property namespaces, and in the table they are associated to the latter. /elements/1.1/ does not define these properties. + The properties dc.contributor, dc.coverage, dc.date, dc.format, dc.identifier, dc.relation, dc.rights, dc.source, dc.subject, are to be INTRODUCED, as defined in /elements/1.1/ namespace. Some of them are now meant to define values in a non-literal range, but the notion of "ranges" does not apply to /elements/1.1/ namespacce properties and so they should be valid (though for legacy purposes). + all dc.prefixed properties should present a note advising authors NOT to use them when a value in the proper range is to be provided (/elements/1.1/ namespace is maintained for legacy reasons, as some properties could have a value not fitting the range as it was defined in 2008 revision; however, now specific ranges have been defined, so it is auspicable that authors conform to them; in that case the more specific /terms/ namespace properties: http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces). - The property dcterms.collection is to be REMOVED as it defines a class of properties in DCMI specification, not a real property - The properties dcterms.hasFormat, dcterms.hasPart, dcterms.hasVersion, dcterms.isFormatOf, dcterms.isPartOf, dcterms.isReferencedBy, dcterms.isReplacedBy, dcterms.isRequiredBy, dcterms.isVersionOf, dcterms.references, dcterms.relation, dcterms.replaces, dcterms.requires, dcterms.source, dcterms.subject are to be REMOVED, because per spec these properties are meant to define non-literal values and as such <meta@name> is not suitable. These properties are ONLY to be defined with <link@rel> elements ( http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms). + Properties whose value can reasonably be either a literal or a non-literal surrogate should be marked with a note stating that, if a resource non-literal reference is to be provided, it is better to use a <link rel="dcterms.property" href="reference" title="literal definition" /> rather a <meta> element whose content is a string. These properties are those defined in the http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions list with a proper "synonim" field is present. Note, however, that this selection, differently from the previous one, is personal and based on common sense (a value in the Agent class can be defined either as a name or as a reference to a personal profile, but a date is basically a string and there's no reason to express it as a reference, even if ranges are respected). + Prefix structures, both in namespace definition <link rel="schema.DCTERMS/DC"> and in properties <meta name="DCTERMS/DC"> should be capitalised both in existing properties and in those defined in this message (I wrote them lowercase for the sake of uniformity). Please allow these changes in order to align the table to DCMI spec. Thanks in advance. Andrea Rendine
Received on Sunday, 15 March 2015 14:07:35 UTC