Hi, all -- 
   I've been in on Ricky's discussions, and I agree that with some very 
minor tweaking to the element definitions, this approach will be easy for 
those of us who need it and transparent to those who do not, esp. if we 
have the capability to group or nest elements in our syntax.  Unlike the 
separate packages Tony posits below, I envision 1 package thusly (and for 
any of you new to this, the example below is to illustrate the concept, 
NOT the coding!):

<package>
      title = How to attract the wombat
      creator = Cuppy, Will.
      publisher = Dennis Dobson
      date = 1950
      subject = Wombats
      type = text.book
      <group>
            date = 1997
            publisher = Harvard University Library
            format = PDF
            type = online surrogate
            ID = <URL:http://marsupial.harvard.edu/wombat.pdf>
      </group>
</package>

More levels of nesting could used if appropriate.  For the purposes of 
resource discovery, the grouping could be used or ignored by any given 
search engine.

One more comment to follow on Arthur and Jon's messages: some months ago, 
I raised the point that we anticipate large quantities of DC data to be 
generated from existing data in other schemes, and that therefore the 
definition of Resource Type as being drawn from a single authoritative 
list was unrealistic.  I would guess that more data will be converted 
into DC than created in DC, and we have to take that into account.  This 
view received some support, and I sincerely hope the definition will be 
changed to admit other vocabularies to be used in the Resource Type 
element.   

Having an "official" DC scheme for values in the Resource Type element is 
great, but  DC aware engines ought to be able to make use of vocabulary 
in the element as long as it is drawn from any registered scheme it 
knows it can handle, or alternatively, to drop the scheme qualifier (the 
Canberra Rule, remember) and accept the content anyway.

--Robin

On Tue, 23 Sep 1997, Tony Gill wrote:

> I like the approach to 'the surrogacy problem' proposed by Ricky; it's
> simple to understand (and therefore simple to explain to others), easy
> to use, and should be able to accommodate sufficiently rich information
> for resource discovery purposes; I don't think the 'assumed and
> unspoken' surrogacy is problematic in this context.
> 
> However, as Ricky points out in an earlier message, it will require some
> careful adjustments to both the element definitions (which need
> overhauling anyway IMO) and the scope of DC itself, so I'm looking
> forward to seeing the RLG proposals in Helsinki. It will also mean that
> TYPE will need to store a lot more than just Internet MIME types!
> 
> Is there any mileage in the idea of creating separate DC 'packets' for
> each object in the chain of surrogacy? Something along the lines of:
> 
> <META NAME=package.begin.1 CONTENT="Dublin Core">
> <Information about an original painting for example>
> <META NAME=package.end.1 CONTENT="Dublin Core">
> 
> <META NAME=package.begin.2 CONTENT="Dublin Core">
> <Information about a photo of the painting>
> <META NAME=package.end.2 CONTENT="Dublin Core">
> 
> <META NAME=package.begin.3 CONTENT="Dublin Core">
> <information about a digital image acquired from the photo>
> <META NAME=package.end.3 CONTENT="Dublin Core">
> 
> This approach would help differentiate the different objects in the
> chain of surrogacy, if people think that this level of delineation is
> necessary... thoughts?
> 
> Another possible problem: There used to be an assumption that element
> order could not be relied upon as a way of encoding information; is that
> still the case? Would that also apply to stuff between <start> and <end>
> tags?
> 
> T.
> 
> Ricky Erway wrote:
> 
> > We will likely advocate (for people using the Dublin Core for a
> > variety of resources, including non-web resources) describing the
> > original always and if there is a surrogate, also describing the
> > surrogate in the same "record" by repeating the appropriate tags in a
> > second tag set.
> > 
> > So, if you have an image of a painting, first describe the painting,
> > then repeat the elements necessary to describe the surrogate.  This
> > reflects our thinking that when someone is looking for a painting
> > on the web, they'll call it a painting, even though they may know
> > it's impossible to have a painting on the Web (unless it's created
> > using PC Paint!).  The surrogacy is assumed and unspoken.
> > 
> > creator: VanGogh
> > title: Starry Night
> > publisher: MOMA
> > date: 1889
> > type: painting
> > 
> > creator: Nicolas Pioch
> > title: Image of Starry Night
> > publisher: WebMuseum
> > date: 1996-05-20
> > type: image/jpeg
> > 
> > -- and if it's important to describe the photograph that was scanned
> > perhaps a middle set of elements is called for!
> > 
> > The point is that users will look for the original thing, so you want
> > to supply that metadata.  It could be that the only important aspect
> > of the surrogate is its URL, but some additional info about the
> > surrogate might be useful -- especially for this example, where there
> > are many surrogates on the Web.
> 
> 
> -- Tony Gill ----------------------  Programme Leader: ADAM & VADS --
>  Surrey Institute of Art & Design * Farnham * Surrey * GU9 7DS * UK
>       Tel: +44 (0)1252 722441 x2427 * Fax: +44 (0)1252 712925
> -- [log in to unmask] -- http://adam.ac.uk -- http://vads.ahds.ac.uk/ --
> 
> 

Robin Wendler  ........................     work  (617) 495-3724	
Office for Information Systems  .......     fax   (617) 495-0491
Harvard University Library  ...........     [log in to unmask]
Cambridge, MA, USA 02138  .............