W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

[whatwg] MetaExtension and Dublin Core revision

From: Andrea Rendine <master.skywalker.88@gmail.com>
Date: Tue, 17 Mar 2015 15:15:18 +0100
Message-ID: <CAGxST9=vRu0n9cWoTp-ZmzDrMSAFVtXyTK3wjvTi1FLyko+RCA@mail.gmail.com>
To: whatwg@whatwg.org
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.
Received on Tuesday, 17 March 2015 14:15:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:33 UTC