When I start using the encoding below will that be in line with the
expected cld profile?
<cld:hasService xsi:type="cdl:SRUbaseURL">
<cld:hasService xsi:type="cdl:Ztarget">
<cld:hasService xsi:type="cld:URL">
---
My proposal about DCX is indeed a dcx namespace "owned" by DCMI, but
"freely available" for implementers to
use for any new terms in their application as they please. But the main
part of the proposal is that we can define application profiles with
qulified DC as basis. Requesting DCX as schema means that you do not
have to know the exact application profile or schema but you can be sure
that at least the dc and dcterms terms are used.
This allows data providers to provide "enriched" data to different data
requestors. This is convenient in distributed metasearches were you do
not know a priori which schemas are available and what these schemas
actually mean. When a data requestor sees that a data provider supplies
additional terms he may start using them if he likes. The alternative
would be that he can only ask for DC simple and never become aware of
the possible enrichments.
Additionally to this it would be good to have a (more or less central)
mechanism to make such additional terms and their meaning known to the
outside world. This concept would allow for a much faster adaptation of
provider and requestor applications.
Theo
>>> [log in to unmask] 8/27/03 10:33:20 nm >>>
Theo said:
> Sometime ago we had some discussion on collections and
> services. I proposed to make the base address of a service
> that gives access to the object descriptions, a part of the
> collection description. The main objection was that there
> could be more services giving access to the same collection
> and that a single service may give access to the description
> of several collections.
I'm not sure the objection was to including the base address of the
Service in the CLD at all?
Rather, I think the argument was that the Service(s) that provide
access
to a Collection are distinct resources from the Collection and we
might
want to provide separate metadata records about Services as resources
with their own identity.
On those grounds, in the collection description, the base address of
the
Service should be provided as the value of an attribute/property other
than dc:identifier, i.e. as the value of a sub-property of
dc:relation,
like hasLocation (or hasService or isMadeAvailableBy or whatever name
we
might agree on). And a single collection metadata record might contain
multiple occurrences of that attribute/property.
Further metadata about Services would (from the "viewpoint" of the
Collection metadata record) be what Andy's proposed abstract model
http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/
calls "related metadata" or a "related resource description".
I think this fits exactly with what Ann said at
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0307&L=dc-collections&D=1
&T=0&O=D&P=56
> Although the term "collection description" may not apply to
> the type of description that I need, both types of
> descriptions may serve the same purpose. What I need is
> descriptions of "seachable targets". These targets contain
> the descriptions of objects that may be from different
> collections. The object descriptions should contain the link
> (URL, URN or OpenURL) to the actual digitized object or the
> service giving access to an object (e.g. document delivery).
> The object description should also contain information on the
> collection it is being part of. Sometimes we have that
> information, sometimes not. Having found such an object we
> might want to locate more objects from that collection. The
> key element to do that is to know an address where to look
> for more objects of that collection. So we need the address
> of the collection description and from that collection
> description we should find out the services giving access to
> search and retrieval of the object descriptions. As Ann
> pointed out there can be different access methods, so we need
> to identify these access methods separately.
>
> In The European Library project we use <dc:identifier> with
> several encoding schemes (SRUbaseURL, URL, Ztarget) for this
> purpose with the tel namespace.
>
> I have two questions:
> 1) For what purpose will collection descriptions be used if
> one cannot figure out the services for search and retrieval
> from the collection description?
I agree that this is a "functional requirement" that collection-level
metadata should support.
> 2) Does it make sense to try to keep aligned with the
> collection description name space for this purpose or should
> I just leave these encosing schemes part of the "tel"
> namespace. This question has to do with a more fundamental
> problem. Trying to introduce terms in a namespace when these
> are needed for providing some functionality and then finding
> out that other namespaces have adopted the same term also.
At this precise point in the development process, I don't think we
(this
WG) can make any categorical assurances about the URIs for the
properties we are discussing/proposing here.
As Andy noted in his last message, some of these properties _may_ be
candidates for the DCMI "dcterms" namespace, but it seems unlikely
that
they will all be given that status, I think.
On the specific subject of encoding schemes, I think there is work in
progress to enable the registration of encoding schemes with DCMI:
http://www.dublincore.org/usage/documents/process/#five.
but I'm not sure of the current status of this effort, and I'm not
sure
whether registering an encoding scheme with DCMI implies assigning a
DCMI-owned URI or whether it encompasses publishing the use of your
own,
independently-assigned URI.
> To avoid the problems like mentioned in the second question
> we need a generic schema DCX (Dublin Core eXtended) and
> perhaps a generic namespace (dcx). DCX means that records may
> contain terms from other namespaces when they could not -
> within reason - be expressed by terms from the dc and dcterms
> namespaces. Applications are supposed to use the terms they
> know and ignore the terms they don't know. When we put these
> extra terms in the dcx namespace they can be shared more
> easily, avoiding records containing more namespace
> declarations than actual data and avoiding changing
> namespaces for terms that are already in use. The use of the
> DCX schema avoids the need to know all schemas that almost
> pure DC but have only a few extensions.
I'm not sure I fully understand this suggestion. Are you proposing a
dcx
namespace "owned" by DCMI, but "freely available" for implementers to
use for any new terms in their application please? Or managed by the
Usage Board?
Pete
|
