Hi Pete,
Thanks. For the time being we will use the tel namespace until the
collection description profile is stable and we will use "hasService"
instead of identifier.
It may be interesting for the DC-collections group to know how we
actually use these terms. We make se of aggregated searches were we can
find a mixture of different object types. One of those object types can
be a collection with a SRU or Z39.50 service attached to it. As soon as
our TEL portal finds such a collection it offers the user the option to
make this service a new or extra target for searching. Conventional
portals have a fixed internal list of targets, but in case of TEL the
list of targets may be the result of a search. This is pretty cool but
also very useful.
With respect to DCX: provided metadata are meaningless until "someone"
finds out what an "unknown" term represents. If such a term then prooves
to be meaningfull the application or the users interpretation may be
changed. Without DCX nobody would be aware of the existence of the terms
because you only ask for known schemas being probably only DC.
My approach is "retrieved metadata" driven rather then "requested
metadata" driven. This applies mainly to SRU and OAI were you have to
request a schema. In our TEL portal we translate and display all the
terms that are defined in the TEL metadata registry but when the portal
receives terms that are not in there it will display the XML tag name.
This is extremely useful for users that want to add their own
functionality related to received metadata - but unknown to TEL - to
the portal . And this is important in relation to what I described above
with respect to collection descriptions: we do not know what collections
will be accessed and what their metadata schemas are, unless they are
part of TEL.
Theo
>>> [log in to unmask] 8/28/03 7:37:05 nm >>>
Hi Theo,
> 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">
I think that's really several separate questions ;-)
1. what is the "local name" of the property used to describe the
relation between a Collection and a Service?
2. what is the URI assigned to that property ("which namespace is it
in", if you like)?
3. should we separate encoding schemes to identify the "type" of
Service
(or the type of URI)?
4. what are the URIs assigned to those encoding schemes (the namespace
they are in)?
On question 1, if we are agreed that such a property is required, then
I
imagine we can probably reach consensus on a name quite quickly.
In a project Ann and I are involved in for JISC, we have used a
"hasService" property.
I think I said at one point that I felt the name "hasService"
described
the type of the object of the relation rather than the nature of the
relation itself, and on those grounds it's perhaps slightly at odds
with
the names of the DCMI-approved refinements of dc:relation, but I don't
feel very strongly about that - and names like "isMadeAvailableBy",
"isAccessedBy" aren't very elegant and I haven't come up with a good
alternative in that style.
On question 2, I'm sorry, but I don't think we can give a categorical
answer at the moment. I suspect (but I can't promise!) we will
probably
need to declare a namespace for some of the terms specific to this
profile. e.g.
<dccd:hasService xmlns:dccd="http://dublincore.org/collections/#">
(N.B. that's just an example, not a concrete proposal! Also it's the
URI
that matters not the prefix used)
FWIW, in the JISC project, we used an application-specific namespace:
<my:hasService xmlns:my="http://www.mimas.ac.uk/iesr/profile/#">
Question 3 is a topic we should discuss:
If we adopt a hasService attribute (or equivalent), do we need to
specify the "subtype" of the URI which is used as a value of a
hasService attribute?
If the answer is yes, should we use encoding schemes to carry this
information? Or does it require some other mechanism?
The answer to question 4 is similar to that for question 2!
> 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.
This probably isn't the forum to pursue this discussion - the
dc-architecture mailing list would be better.
I think you are asking for a generic "application profile" (let's call
it "extended DC") which permits the terms associated with the
dc/dcterms
namespaces (i.e. "qualified DC"), plus in addition _any_ other terms
as
long as those additional terms are associated with a _single_
namespace
(say http://purl.org/dc/x/)? Have I understood that correctly?
Thinking in OAI terms, I can see that this provides an "off-the-shelf"
option for a data provider to encode/expose some data without
deploying
their own application-specific XML namespace and creating their own
application-specific metadata format. And as a service provider I can
_request_ that same metadata format from multiple data providers,
rather
than having to know in advance I need to request
data-provider-1-extended-dc format from data-provider-1,
data-provider-2-extended-dc format from data-provider-2 etc.
But when I come to _process_ that data, having a single "open" XML
_namespace_ doesn't really help, does it?
Unless I know the semantics you intend to convey using that XML
element,
and have programmed my application accordingly,
<dcx:jabberwock xmlns:dcx="http://purl.org/dc/x/">....
is just as "meaningless" to me (as a human reader or an application
program) as
<myapp:jabberwock xmlns:myapp="http://my.org/terms/">....
or
<ex:jabberwock xmlns:ex="http://example.org/terms/">....
The key is (as I think you suggest in the last couple of sentences
above) the disclosure/discovery of semantics. But I don't think that
depends on a choice of URI or XML namespace? It depends rather on
shared
conventions for publishing and accessing such information (e.g. the
what-should-a-namespace-URI-resolve-to question, RDDL, and the
scope/coverage of applications like metadata schema registries).
I think you could probably make your argument for a generic "extended
DC" application profile _without_ requiring that the "extension" terms
must be associated with a single namespace. (i.e. extended DC = dc,
dcterms and anything else!)
Having said all that, I'm still not sure whether it would be useful or
not! ;-)
Pete
|
