RE: agree or not to the TTWG response about your comment

At 2:47 PM -0400 9/14/06, Glenn A. Adams wrote:
>Al,
>
>In a recent message, you note that no details were provided by the
>TTWG to back up the statement in DFXP 1st LC Disposition of Comments [1]
>(as referenced by DFXP 2nd LC Disposition of Comments [2]) that:
>
>"there is sufficient difference of usage and intended semantics to
>retain these items in the TT AF metadata vocabulary"
>
>To help elaborate this statement, I would like to offer the following,

Thank you, Glenn, for this detailed workup.  I do have some exceptions
to take within it, as noted below.

>while making reference to the Dublin Core Metadata Element Set (DCMES)
>1.1 [3].
>
>1. DCMES defines the semantics of Element Name "Title" as follows:
>
><quote>
>Definition: A name given to the resource.
>Comment: Typically, Title will be a name by which the resource is
>formally known.
></quote>
>
>2. DCMES defines the semantics of Element Name "Description" as follows:
>
><quote>
>Definition: An account of the content of the resource.
>Comment: Examples of Description include, but is not limited to: an
>abstract, table of contents, reference to a graphical representation of
>content or a free-text account of the content.
></quote>
>
>3. DCMES defines the semantics of Element Name "Rights" as follows:
>
><quote>
>Definition: Information about rights held in and over the resource.
>Comment: Typically, Rights will contain a rights management statement
>for the resource, or reference a service providing such information.
>Rights information often encompasses Intellectual Property Rights (IPR),
>Copyright, and various Property Rights. If the Rights element is absent,
>no assumptions may be made about any rights held in or over the
>resource.
></quote>
>
>When the TT WG reviewed these definitions during the DFXP 1st Last Call,
>we noted that the term "resource" as used in these definitions is
>defined
>in [3] as follows:
>
><quote>
>Here an information resource is defined to be "anything that has
>identity". This is the definition used in Internet RFC 2396, "Uniform
>Resource Identifiers (URI): Generic Syntax", by Tim Berners-Lee et al.
>There are no fundamental restrictions to the types of resources to which
>Dublin Core metadata can be assigned.
></quote>
>
>>From this description of "resource", the TTWG concluded that, due to
>the invocation of RFC2396, the intended semantics was effectively an
>entity that would (could) be returned by dereferencing a URI, but, and
>this is the key to our understanding, <phrase role="strong">without
>consideration of a resource fragment</phrase>.

That is counter to RFC 2396, in that in this specification the #fragment
part is part of, and not appended to, what is considered to be the URI.

Hence a reference *including the #fragment part* to an ID-bearing
XML element isolates that element as an identified resource, suitable
for annotation with Dublin Core elements and RDF, in general.

The reason that I press this matter is that the architecture adopted
by the RDF-in-HTML task force which puts metadata on arbitrary elements
throughout the DOM tree is in part in response to requests from the
accessibility review of HTML4.  This uses the same rule that @about
defaults to the parent, the containing element, if not specified.

>This conclusion was
>reinforced by our review of the following additional documents
>referenced by the Dublin Core Metadata Initiative:
>
>1. Expressing Dublin Core in HTML/XHTML meta and link elements [4]
>
>in which the definition of "resource" is again described in terms
>similar to that of a file or document:
>
><quote>
>a resource is anything that has identity. Familiar examples include an
>electronic document, an image, a service (e.g., "today's weather report
>for Los Angeles"), and a collection of other resources. Not all
>resources are network "retrievable"; e.g., human beings, corporations,
>and bound books in a library can also be considered resources.
></quote>
>
>and in which the examples given clearly refer to an HTML/XHTML document
>as a whole:
>
><head profile="http://dublincore.org/documents/dcq-html/">
><title>Expressing Dublin Core in HTML/XHTML meta and link
>elements</title>
><meta name="DC.title" lang="en" content="Expressing Dublin Core
>in HTML/XHTML meta and link elements"/>
>...
></head>
>
>2. Using Dublin Core [5]
>
><quote>
>A metadata record consists of a set of attributes, or elements,
>necessary to describe the resource in question. For example, a metadata
>system common in libraries -- the library catalog -- contains a set of
>metadata records with elements that describe a book or other library
>item: author, title, date of creation or publication, subject coverage,
>and the call number specifying location of the item on the shelf.A
>metadata record consists of a set of attributes, or elements, necessary
>to describe the resource in question. For example, a metadata system
>common in libraries -- the library catalog -- contains a set of metadata
>records with elements that describe a book or other library item:
>author, title, date of creation or publication, subject coverage, and
>the call number specifying location of the item on the shelf.
></quote>
>
><quote>
>Another way to look at Dublin Core is as a "small language for making a
>particular class of statements about resources".
></quote>
>
><quote>
>Although the Dublin Core was originally developed with an eye to
>describing document-like objects (because traditional text resources are
>fairly well understood), DC metadata can be applied to other resources
>as well. Its suitability for use with particular non-document resources
>will depend to some extent on how closely their metadata resembles
>typical document metadata and also what purpose the metadata is intended
>to serve.
></quote>
>
>A RDF/XML example given in this document:
>
><rdf:RDF
>    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>    xmlns:dc="http://purl.org/dc/elements/1.1/">
>    <rdf:Description rdf:about="http://media.example.com/audio/guide.ra">
>       <dc:creator>Rose Bush</dc:creator>
>       <dc:title>A Guide to Growing Roses</dc:title>
>       <dc:description>Describes process for planting and nurturing
>different kinds of rose bushes.</dc:description>
>       <dc:date>2001-01-20</dc:date>
>    </rdf:Description>
></rdf:RDF>
>
>*** Conclusions ***
>
>To bring the above threads to a conclusion, the TTWG
>was faced with a preponderance of evidence that the intention of DCMES
>was "to describe identified resources that are or are similar to a
>document as a whole".

No; it is to describe properties that are same or similar to the properties of
a document as a whole.  The test of similarity is at the DC element
level, not the XML element level.

Rights and description are, at first blush, very nearly the same 
thing for a fragment
as for a published document as a whole.   Title is corrupted by the
way the @title attribute is used and behaves in HTML, I agree.

>In contrast, the requirements for DFXP metadata, as represented by
>
><ttm:title/>
><ttm:desc/>
><ttm:copyright/>
>
>were to support:
>
>* fine granularity at level of individual information elements without
>respect to containing resource;
>
>* unidentified information elements;

Sorry -- I cannot understand this one.  Do you mean un-prefixed element
names?

>
>as evidenced by [6] Section 12:
>
><quote>
>metadata is to be understood as a separable layer of information
>that applies to content, style, layout, timing, and even metadata itself
></quote>
>
>and by the definitions of usage in DFXP wherein the above <ttm:*/>
>element types may appear multiple times in a document as scoped to their
>containing element.
>
>More specifically, the TTWG defined these ttm:* element types
>as counterparts to the same named element (attribute) types as currently
>found in SMIL and SVG, which have similar properties of usage in that
>they may apply to unidentified information that is scoped by an
>arbitrary
>element instance.

Good.  They are consistent with the Dublin Core definitions.

>Our final conclusion was that:
>
>* there was existing, and well-established precedent for like-named
>element types serving identical roles in SMIL, SVG, and in XHTML and
>HTML (in some cases as elements and in other cases as attributes);

Yes, and good to extend the SVG pattern; which has to be distinguished
from HTML.

>
>* dublin core focused on metadata describing documents as a whole and
>document like entities, and not fine grained information sub-entities
>within a document, such as distinct element information items;

This is as explained an erroneous interpretation of DC and the URI RFC.

>* that additional new metadata was needed to satisfy DFXP requirements
>(namely, agent, actor, and role), and that creating two disparate sets
>of metadata elements (with different lineage) was not only unwarranted
>but also unnecessarily complex and confusing;

Debatable.  Complexity is in the eye of the beholder.

>I hope this provides further background, and I would urge you to
>accept the unanimous consensus of the TTWG membership that substituting
>ttm:title, ttm:desc, and ttm:copyright for dublic core metadata items
>is not warranted.

Look, I've already told you I am not interested in filing a formal objection
over this.  In fact, consistency with SVG is a strong argument in this
case because it leaves us with just one crosswalk to do if there is any
significant difference.  We have to reconcile the SVG terms with DC in
any case.

If you just say that "we found the analogy to SVG so compelling that
we based these on that"  I would take it.

You don't need the spurious interpretation in the area of DC vs. 
wholes vs. parts.

Thank you again for this detailed explanation.

Looking forward to your CR.

Al


>Regards,
>Glenn
>
>[1] http://www.w3.org/2005/03/21/DFXPLastCallResponses.html#Issue9
>[2] http://www.w3.org/2005/03/21/DFXP-2ND-LastCallResponses.html#Issue9
>[3] http://dublincore.org/documents/dces/
>[4] http://dublincore.org/documents/dcq-html/
>[5] http://dublincore.org/documents/usageguide/
>[6] http://www.w3.org/TR/2006/WD-ttaf1-dfxp-20060427/#metadata
>
>-----Original Message-----
>From: Al Gilman [mailto:Alfred.S.Gilman@ieee.org]
>Sent: Tuesday, September 12, 2006 1:09 PM
>To: Thierry MICHEL
>Subject: Re: agree or not to the TTWG response about your comment
>
>At 1:33 PM +0200 8/28/06, Thierry MICHEL wrote:
>>Al Gilman,
>>
>>Could you please say if you agree or not to the following response
>>of the TTWG about your comment:
>
>Do not agree.
>
>The Working Group has offered conclusions only, without and factual
>evidence to support them.
>
>The explanation that being self-contained would facilitate
>interoperation is debatable. Without more explanation as to how you
>are postulating the scope of interoperation and measuring its quality
>this cannot be accepted simply as stated. The claim is made that the
>DXFP sense of these terms is different from the Dublin Core sense;
>but it is not explained how.
>
>An acceptable disposition might arrive at the same conclusion if you had
>put
>
>-- a clear compare and contrast between the DXFP meanings of these
>terms and their Dublin Core meanings in the specification, and
>
>-- some use cases where it is important to observe these distinctions
>in the comment response.
>
>So, I consider the response non-responsive to the comment.
>
>However, I do not regard this defect as a show-stopper that should
>bar the advance of the format.
>
>Al
>
>>
>>Issue 9: Coments - [DFXP Last Call] use Dublin Core where applicable]
>>
>>      * From:  <Alfred.S.Gilman@IEEE.org>
>>      * Date: Thu, 21 Apr 2005 13:24:18 -0400
>>      * Archived:
>>http://lists.w3.org/Archives/Public/public-tt/2005Apr/0038.html
>>
>>
>>Response of the TTWG about your comment is available at
>>http://www.w3.org/2005/03/21/DFXPLastCallResponses.html#Issue9
>>
>>
>>Thanks.
>>--
>>Thierry Michel
>>W3C

Received on Thursday, 14 September 2006 20:38:01 UTC