Tom

I think your version is indeed much clearer than mine so I'm happy to
go with it.

cheers
Andrew

On 23 Jun 2004, at 4:18 AM, Diane Hillmann wrote:

> Tom:
>
> Very clear.  I think your version is slightly preferable since it pulls
> apart all the relevant issues, though Andrew's was fine, too.
>
> Diane
>
> At 05:18 PM 6/22/2004 +0200, you wrote:
>> On Thu, Jun 17, 2004 at 10:26:35AM +0200, Thomas Baker wrote:
>> > On Thu, Jun 17, 2004 at 05:24:04PM +1000, Andrew Wilson wrote:
>> > > >Here is another draft of the CD proposal decision which tries to
>> > > >accommodate the discussions over the last few weeks. The third
>> paragraph,
>> > > >in particular, has been significantly rewritten. For your
>> consideration
>> > > >and comment.
>> >
>> > To facilitate quoting and comment, I have attached below the
>> > decision draft in plain text.
>> ..
>> > Title:         Decision on proposal for a Collection Description
>> profile
>> > Shepherd:      Andrew Wilson
>> > Identifier:
>> http://dublincore.org/usage/decisions/2004/2004-02.shtml
>> > Date:          2004-06-17
>>
>> Dear all,
>>
>> The discussion last week between Pete, Diane, Andrew, Stuart,
>> and Andy succeeded in justifying the decision to reject the
>> term "Is Available At".  However, the text in the latest draft
>> decision (2004-06-17) does not in my opinion state the issues
>> clearly enough.
>>
>> The draft says:
>>
>> > The UB discussion of the proposed refinement "isAvailableAt"
>> > raised the issue of the ambiguity between identification
>> > and location (access). The proposal from the Collection
>> > Documentation WG did not adequately provide for unambiguous
>> > differentiation between the functions of identification
>> > and location when describing related resources. This has
>> > the potential to lead to confusion with existing usage of
>> > the dc:identifier property, since it is a common practice of
>> > implementors to use a "locator" rather than an "identifier" as
>> > the value of this property. The likely consequences of using
>> > isAvailableAt as a sub-property of dc:relation in practice
>> > suggest that information about how to access the resource being
>> > described should be provided in some other manner, perhaps as
>> > a new property (such as the Availability element in AGLS or
>> > the MODS property described below). The Usage Board suggests
>> > that a revised proposal, if one is to be submitted for UB
>> > consideration by the Collection Documentation WG, should better
>> > model the differences between "services" (physical and digital)
>> > and "locations" (physical and digital), and should provide for
>> > descriptions of these types of resources in a manner that does
>> > not allow for confusion with existing usage of dc:identifier.
>>
>> I propose replacing the text above with the following:
>>
>>     In the UB discussion of the proposed refinement
>>     "isAvailableAt" -- both at the Bath meeting and
>>     subsequently on the mailing list -- the following points
>>     were made:
>>
>>     -- The Collection Description working group would like to
>>        distinguish between an "identifier" for a resource
>>        (i.e., a string designating the resource described)
>>        and a "locator" usable for accessing that resource.
>>
>>     -- The Collection Description working group also would like
>>        to be able to describe a service which "provides access
>>        to" that resource as an entity in its own right -- with,
>>        in principle, its own set of attributes (i.e., as a
>>        "related resource" related to the resource described).
>>        This was the rationale for proposing "isAvailableAt"
>>        as a refinement of dc:relation.
>>
>>     -- Metadata aggregators such as NSDL and AGLS find that,
>>        in practice, the value of dc:identifier is very commonly
>>        not an "identifier" in the purest sense of the word
>>        (i.e., a unique string not necessarily resolvable to a
>>        Web address), but rather a URL by which the resource
>>        can be accessed (i.e., a "locator").  In doing so,
>>        metadata authors are merely reflecting the endemic
>>        ambiguity between "identification" and "location"
>>        in the context of the Web.
>>
>>     -- Although the intention of the proposers of "Is
>>        Available At" was to point to "a service"
>>        making the resource available, it was feared that
>>        dct:isAvailableAt might be used for the "locator" of
>>        the resource itself.  Such usage would merely compound
>>        the ambiguity already surrounding dc:identifier with
>>        a new ambiguity with respect to dct:isAvailableAt.
>>
>>     -- Specifically, it was feared that if metadata authors
>>        were to put the locators of resources into a refinement
>>        of dc:relation, then the fact that those URIs were
>>        locators of the resource would be lost in the process
>>        of dumbing down.  After dumb-down, an aggregator might
>>        be left with multiple values for dc:relation and have
>>        no way of knowing or inferring which ones were usable
>>        as locators for the resource.
>>
>>     -- It was pointed out that the proposed definition of
>>        "Is Available At" ("The referenced resource provides
>>        access to the described resource") is difficult to
>>        distinguish in its intent from the definition of the
>>        existing element dc:publisher ("An entity responsible
>>        for making the resource available").
>>
>>     In sum, future proposals addressing these issues should
>>     consider the following:
>>
>>     -- As argued by the Collection Description Working Group,
>>        it may be desirable to distinguish more cleanly
>>        between identifiers and locators for the resource
>>        described.  Any proposal to do so, however, should
>>        address the ambiguity inherent in the existing usage
>>        of dc:identifier.
>>
>>     -- It may be desirable to have a property specifically for
>>        information services so that those services can be
>>        pointed to or described as "related resources" -- i.e.,
>>        as entities in their own right.  For the practical
>>        purposes of aggregators, however, it is not desirable
>>        that locators for those services be associated with
>>        properties that are subject to dumb-down to very
>>        broad and generic properties such as dc:relation.
>>        Rather, information about the information service
>>        should be provided in some other manner -- either by
>>        a new top-level DCMI element, by an existing property
>>        from a namespace such as AGLS or MODS, or possibly
>>        by dc:publisher.
>>
>> Tom
>>
>> --
>> Dr. Thomas Baker                        [log in to unmask]
>> Institutszentrum Schloss Birlinghoven         mobile +49-160-9664-2129
>> Fraunhofer-Gesellschaft                          work +49-30-8109-9027
>> 53754 Sankt Augustin, Germany                    fax +49-2241-144-2352
>> Personal email: [log in to unmask]
>