Pete,

>>> [log in to unmask] 15/09/04 08:32:09 >>>
>
> > 1. For an electronic collection I struck the usual question
> > of should I describe the physical collection and indicate how
> > to access it electronically, or should I just describe the
> > electronic collection.  I kind of side-stepped this and used
> > whatever we did previously.
>
> Depending on requirements, I might very well want to describe both
the
> physical and the digital collection, but within any CLD, I think
it's
> very important to be absolutly clear which one is the subject of the
> description.

It is my understanding that in the library world (or here at least)
there is some move towards describing the source object once and
indicating the digital copies are an additional holding.  (Though born
digital alternatives would have a separate description.)  I think this
is partly from a pragmatic motivation, but it is at odds with the whole
DC one-to-one model.  (Though I'm not expecting an answer, just making
an observation.)

> > 5. gen:isLocatedAt and gen:isAvailableAt could do with some
> > more guidance - I wasn't sure what kind of thing was expected
> > in these, I guessed one was physical and the other electronic
> > (in my situation)??

To further clarify, at a more basic level than physical/digital, I just
had no idea of what might be expected to go in these fields (probably a
granularity question) - street address, org name, "3rd floor", service
name, phone number, etc.

> > 9. I am planning to load collection-level records like this
> > into Matapihi (New Zealand's version of PictureAustralia and
> > ImagesCanada), so I still wanted DCMIType=Collection as well
> > as the CLDT so it makes sense alongside "normal" (ie.
> > singular resource) records - I can't trust that applications
> > will know that a CLDT type means it has a DCMIType of
> > Collection (assuming I've understood that relationship correctly).
>
> We're intending to review the CLDT vocabulary, but FWIW, the
intentions
> is that the "terms" in the CLDT vocabulary are all subclasses of
> dcmitype:Collection, so an RDFS aware application would infer that
any
> instance of type cldt:CollectionText (etc) is also an instance of
> dcmitype:Collection. But of course this isn't explicitly documented
> (yet) ;-)
>
> And, yes, I agree it does no harm, and may be a Good Thing, to record
it
> explicitly, rather than expect it to be inferred. And in a non-RDFS
> context, it should be recorded explicitly.

So the question is, if I use DCMIType in my data, is this part of the
DC CD AP or external to it?  ie. should DCMIType be added as an encoding
scheme for dc:type in DC CD AP?

> > 11. Related to this is one contributor who has
> > encyclopedia-like pages consisting of an essay plus multiple
> > images on the topic.  Would this have two dc:type entries of
> > CollectionStillImage and CollectionText?  I always get
> > confused on this stuff...
>
> If the collection is an aggregation of text items and image items
(even
> if there is only one text item or one image item), yes, I think so.

This is the case, so we are saying I should have two entries:
  <dc:type xsi:type="cld:CLDT">CollectionStillImage</dc:type>
  <dc:type xsi:type="cld:CLDT">CollectionText</dc:type>
I imagine this could be a common scenario so it would be nice if it
were mentioned somewhere in the AP doc.

Thanx,
Douglas