Hi Pete,
Yes what you describe is the expected behaviour. However provider 5 may
choose what is best ABC or XYZ or a superset. The dataprovider knows
what is the best schema. One of the advantages of DCX is that providers
do not have to worry about creating extra schemas.
I would expect the following table.
request - possible response
DC - DC
DC - DCX (it is up to the service provider to return an error
message to the user)
DCX - DCX
DCX - DC
DCX - ABC or XYZ and the requestor prays for getting at least some
DC properties
ABC - DCX (it is up to the service provider to return an error
message to the user)
ABC - ABC (normal situation)
ABC - DC (it is up to the service provider to return an error
message to the user)
ABC - error message "we do not support ABC
DCX - error message we do not suport DCX
DC - error message we do not support DC
There are some cases that could be marked as "bad behaviour" but we
have no control over it.
Theo
>>> [log in to unmask] 9/16/03 6:33:37 nm >>>
Hi Theo,
I've sketched a scenario below so that I can understand better how you
see DCX working...
> Now suppose we access a system for which we got the base-URL
> in some way. We do not know which metadata schemas are
> available and even when we know we do not know what they
> mean. So we can only request DC. Now suppose that a system
> has a schema (or application profile) called XYZ which
> consists of DC and some extra elements. Even when our
> application knows that the system can provide XYZ, our
> application will never ask for it because we do not know what
> it means and we will never be aware of the richness of the
> extra metadata that might be available in that schema.
>
> Now suppose that that system would say: we have DC, XYZ and
> DCX. DCX is the same as XYZ, but we do not have to know that.
> We know that DCX means that our application can understand
> the qualified DC terms from the response and might ignore the
> rest. But when we (user, developer) see that it contains
> interesting terms that might be useful we change our
> application to use those extra terms.
>
> So DCX is just an extra name for schemas that are qualified
> DC plus something extra. Asking for DCX we get the extra
> metadata unsollicited. The response may indicate that it is
> DCX or it may give the real schema name (and we pray it
> actually was DCX :-).
In this scenarios I'm using the terms "data provider" and "service
provider" in the sense those terms are used in OAI-PMH.
OAI-PMH works with "metadata formats", which are basically structural
models, described by W3C XML Schemas. I think (but I'm not 100% sure)
that OAI-PMH _requires_ an XML Schema to be associated with a metadata
format.
I'm making the assumption here that DCX can be implemented as a
suitably
flexible XML Schema (with some wildcard wizardy for the non-DC
namespaces that might be included - again I'm not absolutely sure this
is achievable: I remember experimenting with something si ilar a while
ago so I'll check it out).
(I also think there are perhaps some differences between a "metadata
format" and an "application profile" but for this purpose, let's put
that to one side).
Suppose data provider 1 offers
- oai_dc (a metadata format which represents "Simple DC" in the terms
of
Andy's model, and that is mandated by OAI-PMH)
- XYZ (a metadata format that represents a DC "application profile"
that
incorporates "Qualified DC" in the terms of Andy's model, plus
additional properties - here using a QName shorthand - other:foo and
other:bar)
- DCX (same as XYZ)
and data provider 2 offers
- oai_dc (as above)
- ABC (a metadata format that represents a DC "application profile"
that
incorporates "Qualified DC", plus another:foo and another:bar)
- DCX (same as ABC)
and data provider 3 offers
- oai_dc (as above)
- XYZ (as above)
- ABC (as above)
- DCX (same as XYZ)
and data provider 4 offers
- oai_dc (as above)
- XYZ (as above)
- ABC (as above)
- DCX (same as ABC)
and data provider 5 offers
- oai_dc (as above)
- XYZ (as above)
- ABC (as above)
- DCX (a metadata format that represents the "superset" of XYZ and
ABC,
i.e. "Qualified DC", plus other:foo, other:bar, another:foo and
another:bar)
If as a service provider, I request DCX, then
- data provider 1 returns XYZ-as-DCX
- data provider 2 returns ABC-as-DCX
- data provider 3 returns XYZ-as-DCX
- data provider 4 returns ABC-as-DCX
- data provider 5 returns ABC/XYZ-as-DCX
Is that the behaviour you are expecting please?
Thanks
Pete
|