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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Glenn Adams

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:[hidden email]]
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:  <[hidden email]>
>     * 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


Reply | Threaded
Open this post in threaded view
|

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

Al Gilman

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:[hidden email]]
>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:  <[hidden email]>
>>      * 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


Reply | Threaded
Open this post in threaded view
|

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

Glenn Adams
In reply to this post by Glenn Adams


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.

Regards,
Glenn

-----Original Message-----
From: Al Gilman [mailto:[hidden email]]
Sent: Thursday, September 14, 2006 4:38 PM
To: Glenn A. Adams
Cc: [hidden email]
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:[hidden email]]
>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:  <[hidden email]>
>>      * 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


Reply | Threaded
Open this post in threaded view
|

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

Al Gilman

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:[hidden email]]
>Sent: Thursday, September 14, 2006 4:38 PM
>To: Glenn A. Adams
>Cc: [hidden email]
>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:[hidden email]]
>>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:  <[hidden email]>
>>>       * 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


Reply | Threaded
Open this post in threaded view
|

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

Glenn Adams
In reply to this post by Glenn Adams

Thanks (for accepting and for volunteering a good resolution).

G.

-----Original Message-----
From: Al Gilman [mailto:[hidden email]]
Sent: Thursday, September 14, 2006 4:57 PM
To: Glenn A. Adams
Cc: [hidden email]
Subject: 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:[hidden email]]
>Sent: Thursday, September 14, 2006 4:38 PM
>To: Glenn A. Adams
>Cc: [hidden email]
>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:[hidden email]]
>>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:  <[hidden email]>
>>>       * 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