- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Thu, 14 Sep 2006 14:47:25 -0400
- To: "Al Gilman" <Alfred.S.Gilman@ieee.org>
- Cc: <public-tt@w3.org>
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, 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>. 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". 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; 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. 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); * 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; * 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; 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. 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 18:47:32 UTC