> From: [log in to unmask] (Stu Weibel)
> http://www.oclc.org:5046/~weibel/dc4.html
> From: Andrew Daviel <[log in to unmask]>
> .. for those not in the microsoft world,
> http://vancouver-webpages.com/VWbot/DC4.gif
Stu,
These comments are based on your latest draft and Andrew's image.
Overall the report is very clear and I continue to be amazed at your
ability to make sense out of the gradually forming positions of the
group. I think your continuum of positions is a very useful way of
explaining things. A couple of points follow.
Along the same line that Jack was following, the passage
"...this implies that one might well be able to drop away all qualifiers
(including, perhaps, the element names themselves) and still have a
surrogate for the resource that is useful for retrieval."
could be beefed up by saying _why_ it's good: that there's a variety of
users (eg, consumer software, and intermediate info system providers) who
will be handling those resource descriptions -- some sophisticated, some
naive -- and the elements should continue to "work" even for the naive ones.
Your references to the figure (the only one I could read was Andrew's gif)
don't quite match for me. For example, your reference "of central interest
is the _Element Value_ itself" has no counterpart; I see Element Name and
Content in the figure, but no Element Value. "Content" as a label is risky
because it tempts the usual confusion between element content and resource
content; better to use "Element Content" or "Element Value", though I prefer
the former because it's consistent with the HTML "content=" attribute.
The pointy blobs labeled "Link" in the Figure aren't clearly explained.
You make several implicit references when talking about the Scheme link
(enough to get by), but the Element Name link shown has no reference
from the text.
"The unresolved problem with the application of sub-element
names is how to identify the authority for the subelement name."
^^^^^^^^^
Your first use of "authority" above needs better explanation, eg, do you
mean _naming_ authority? and what does that mean? ... Also, you say
later "that figure 1 includes an _authority_ attribute", but I don't
see that in the figure (maybe one of the link blobs?).
You mention the Overloaded Content approach vs. the Rogue Attribute.
First, it would help to say where the term Rogue comes from. Second,
the overloaded approach, which I've never liked, could use another plug
(I'm playing devil's advocate). One advantage to it is that a harvester
that doesn't recognize the non-content gunk between the parens in
NAME="DC.SUBJECT"
CONTENT="(SCHEME=LCSH) Computer Cataloging of Network Resources"
will index that gunk, thus enabling searches like these to work:
find stuff with LCSH subject headings
find stuff with that actually use scheme in the subject
Finally, in the section heading
The Co-evolution of the Metadata Architecture of the Web
to which parties does the "Co-" refer? Maybe it would be clearer as
The Co-evolution of Web Metadata Architectures
-John
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John A. Kunze +1 415-502-6660 Mgr, Advanced Tech Group
530 Parnassus Ave, Box 0840 [log in to unmask] Library and Center for
San Francisco, CA 94143-0840 Fax: 415-476-4653 Knowledge Management
=-=-=-=-=-=-=-=-= University of California, San Francisco =-=-=-=-=-=-=-=-=
|