 |
 |
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