 |
 |
Douglas, > 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. Ah, right. The data model underpinning the DC CD AP is one of several resource types/entity types (Collection, Location, Item, Agent, Service etc) and the relationships between those entities. See the diagram in the introoduction to the DC CD AP. But we undertook - in the first instance at least - to prescribe a set of properties to describe _only_ the attributes of the Collection and the relationships in which the collection is source/subject. And that is what the DC CD AP currently covers. It does not provide any information on how to describe a Location, Item, Agent, Service etc etc. That is not to say that implementers won't want to describe those things, just that the DC CD AP is silent on what attributes you describe and what properties are used to represent those attributes. I do sometimes find myself wondering whether it really makes sense to have made this division but we have done. I guess in the future we may extend this work to specify how those other entities are described (and/or "plug in" or build on the outcomes of the work of other DC WGs like the DC Agents WG). So the answer is that for isLocatedIn, DC CD AP expects a reference to a resource of type Location, and for isAvailableVia, it expects a reference to a resource of type Service. That could be just a "value URI" for the Location or Service; or it could be a "related description" of the Location or Service - but DC CD AP has nothing to say (at present) on what properties are used in that related description. (FWIW, when I was thinking about drafting examples, I was thinking that there would just be a value URI supplied for location and service, even if just a sort of placeholder URI.) > 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? You may be right - we shouldn't realy on the inferencing from the CLDT classes. But if it is include it would be with the caveat that the only permissible value from the scheme is dcmitype:Collection! > 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> Yes. > I imagine this could be a common scenario so it would be nice > if it were mentioned somewhere in the AP doc. OK. There is a "user guide" in preparation, BTW. These are the sort of things I imagine it might address - maybe not at the syntax level, but in terms of when you need to repeat properties and so on. Pete