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

At 4:45 PM -0400 9/14/06, Glenn A. Adams wrote:
>Thanks. I agree we may debate the intended meaning of "resource" in
>DCMES, but
>let's not do that.
>
>My only reason for giving a longer version was to demonstrate that we
>had
>actually spent some time thinking about and discussing the usage of DC;
>perhaps we read DC wrong, but we ended up where we are in any case.
>
>Instead, I will accept your suggestion:
>
>"we found the analogy to SVG so compelling that we based these on that"
>
>as the most simple and undebatable response.
>
>Given this more succinct response to the original comment, can you now
>accept the resolution to retain the ttm:* vocab in question under this
>response. If so, then we will report that you accept the revised
>response in our disposition of comments document.

Yessir.

Al

>
>Regards,
>Glenn
>
>-----Original Message-----
>From: Al Gilman [mailto:Alfred.S.Gilman@IEEE.org]
>Sent: Thursday, September 14, 2006 4:38 PM
>To: Glenn A. Adams
>Cc: public-tt@w3.org
>Subject: 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:57:07 UTC