Clayphan, Robina wrote:

> Thanks to all of you for this discussion which has certainly shed some
> light on the issues surrounding the desire to re-use MODS terms in
> DC-Lib.  My current understanding is that, despite the best efforts of
> Ray and colleagues at LC, there appear to be insuperable obstacles in
> re-using MODS elements in a DC application profile due to the two
> formats being based on fundamentally different models. 
> 
> Is it premature to draw the conclusion that we probably have to abandon
> the idea of re-using MODS elements in DC application profiles?  This
> issue has been around since the UB decisions of 2002 [1,2,3] and if we
> must now find a different solution then I would like to start making
> some progress on it. 
> 
> If we are to look for an alternative there are three terms to make some
> decisions about: dateCaptured, edition and location.  The most obvious
> alternative solution is to try and identify the terms we require from
> other namespaces that share the same model.  As a starting point Ann has
> suggested using the term "isLocatedAt", proposed by the Collection
> Description WG [4], instead of "location".   This term refines
> dc:relation and the definition given in the CDAP is "A location of the
> resource".

Which even if I say so myself is, umm, a bit thin on the detail ;-)

> This does not seem to conflict with the requirement of
> DC-Lib, which is to identify the organization holding the resource [5]. 

Actually, I think an organisation and a location are quite different things!

The use of isLocatedAt in the DC CD AP is based on the Is-Located-In 
relation in Mike Heaney's Analytical Model of Collections and their 
Catalogues [1] where he notes very clearly

===
The place (identified physically or electronically) where a
Collection is held.
Note: It is important to distinguish between the place and the
institution responsible for the place; the latter is represented in this
model by the term Administrator.
===

So the value of the proposed isLocatedAt property is intended to be a 
"place", not an organisation (an Agent).

In general conversation we tend to blur the distinction between, say, 
the University of Bath Library as the organisation (Agent) and the 
University of Bath Library as place/repository/building (Location). And 
in some application data models too, the distinction may not be worth 
making, but in the Heaney model it is made, and the DC CD AP is intended 
to reflect that.

Of course, it may be that in DC-Lib, you really _do_ want to talk about 
the "place"/repository etc, rather than the organisation, in which case 
the property would (probably) become a candidate for your requirements.

But, N.B., the DC CD property is currently only a suggested term (and as 
you highlight, not a terribly well documented one!)

Pete

-- 
Pete Johnston
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619    fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/