[OAI-implementers] Qualified Dublin Core

Tue Aug 10 17:50:46 EDT 2004

I wasn't actually promoting the idea that the OAI should provide a
canonical DCQ wrapper schema, merely that such a canonical schema would be
useful. The DCMI would seem the logical authority to put out such a schema
though from Pete's comments it seems that is unlikely or at least not
going to happen soon. Given this situation then it may be that the OAI is
a reasonable second-best.

Should a canonical DCQ schema emerge (at whatever location) I think the
OAI guidelines should recommend it as a way to encourage interoperable
exchange of pure DCQ metadata.

Where I disagree with Tim is that I don't see the widespread use of
DCQ+extras as a reason for not having a pure-DCQ schema. There will be
some who need only pure-DCQ. There will be instances such as the case the
Jeff is talking about, that DCQ will be a default provided in
non-localized code. Also, by the same arguments that the holder/creator of
metadata is often the best person to crosswalk metadata to DC from their
internal format; that person may also be best placed to crosswalk their
DCQ+extras to DCQ for export to services that don't understand the extras.
The xs:substitutionGroup mechanism may be able to provide mappings in many
cases but one can easily imagine more complex situations. There are also
buying-power arguments here; in a world with many metadata providers the
"little people" may find obvious conformance a good route to inclusion
where larger collections can expect extra service-provider effort.

Cheers,
Simeon

On Tue, 10 Aug 2004, Young,Jeff wrote:
> Thanks for you comments, Tim. Here are my thoughts.
>
> I'll have to review Pete's arguments, but it occurs to me that if all
> creators of metadata formats (e.g. Library of Congress) punted on the
> container issue, efforts like mine to build interoperable distributed
> systems would be seriously taxed. I share your concern, though, that OAI
> isn't the best host for a generic DCQ schema for the same reason it's not
> the best host for oai_dc. For example, I want to disseminate DC records via
> SRW. I feel a little dirty using the oai_dc schema, but what would be
> better? (I have some radical ideas about how this could be resolved, but
> they are unlikely to catch on. For the terminally curious, check out
> http://errol.oclc.org/xmlregistry.oclc.org.html?set=XMLSchemas&metadataPrefi
> x=oai_dc&verb=ListRecords).
>
> I have no qualms about the proliferation of container schemas that merely
> include DCQ other than to say I hope communities reuse them whenever
> appropriate. My only concern is the proliferation of containers containing
> pure DCQ. Specifically, my plan is to add a pure DCQ metadataFormat to
> DSpace and my decision on the matter will affect dozens of repositories.
> Because of the impact, I would hate for my uncritical proprietary solution
> to become the de facto standard.
>
> Jeff
> > -----Original Message-----
> > From: Timothy W. Cole [mailto:t-cole3 at uiuc.edu]
> > Sent: Tuesday, August 10, 2004 3:47 PM
> > To: 'Young,Jeff'; 'Simeon Warner'; oai-
> > implementers at oaisrv.nsdl.cornell.edu
> > Subject: RE: [OAI-implementers] Qualified Dublin Core
> >
> > I take your point, Jeff, and Simeon's as well, but I still don't entirely
> > agree. Let me preface my response as follows:
> >
> > There seem to be three major arguments (at least) that have been advanced
> > for why OAI should host a canonical container XSD for qualified DC similar
> > to the oai_dc.xsd currently hosted by OAI for simple DC:
> >
> > reason 1. It would facilitate OAI metadata providers who want to provide
> > metadata records in qualified DC and it is uncertain when or even whether
> > DCMI will ever choose to assign a top-level DCQ namespace and make an XSD
> > usable for that purpose. For the reasons Pete discussed, DCMI doesn't seem
> > inclined to want to do this.
> >
> > reason 2. It would cut down on redundancies in namespaces and schemas, and
> > thereby facilitate development of web services / automatic crosswalk
> > applications like the ones you're building.
> >
> > reason 3. Harvesters need the assurance that harvesting records only in
> > canonical formats brings.
> >
> > I'm becoming convinced of the strength of reason 1. Though I still have
> > qualms about whether OAI really is the best location for canonical
> > metadata
> > schemas and namespaces of this sort, at least the XSD we're talking about,
> > since it imports namespaces and schemas that are maintained on the DCMI
> > site, would be relatively simple and low maintenance. So, maybe adding an
> > OAI-blessed XSD for qualified DC wouldn't be a bad idea in and of itself
> > (though of course it sets a pesky precedent, and I have no idea how those
> > closer to day-to-day maintenance of the OAI site feel about doing this).
> >
> > I'm unconvinced of reasons 2 and 3, based on the following:
> >
> > - There are that I know of offhand 5 XSDs currently being used by OAI
> > metadata providers for metadata formats based on qualified DC. They are
> > (in
> > order of frequency of use):
> >
> > http://www.language-archives.org/OLAC/1.0/olac.xsd
> >
> > http://ns.nsdl.org/schemas/nsdl_dc/nsdl_dc_v1.02.xsd
> > (I'm treating the v1.00 and v1.01 versions of the NSDL XSD as congruent
> > with
> > v1.02 for this discussion.)
> >
> > http://IMLSDCC.grainger.uiuc.edu/schemas/cdp_dc_v1.00.xsd
> >
> > http://cicharvest.grainger.uiuc.edu/schemas/QDC/2004/07/14/CICQualifiedDC.
> > xs
> > d
> >
> > http://epubs.cclrc.ac.uk/xsd/qdc.xsd
> >
> > The first three XSDs all add to qualified DC, that is they all include
> > additional elements, refinements, and/or encoding schemes not included in
> > the dc, dcterms, or dcmitypes namespaces. So sites using the first 3
> > schemas
> > would likely not be able to switch over to a "pure" canonical qualified DC
> > schema even if one were available. The 4th XSD on the list is for a
> > project
> > we're just starting here at Illinois with partners in the CIC. At present
> > our CIC qualified DC schema does not augment qualified DC, but my
> > expectation is that it will do so soon, so again, we'll likely not be able
> > to switch over to a pure canonical XSD for qualified DC even if one
> > becomes
> > available.
> >
> > This suggests to me that we're going to see a large number of instances
> > where projects choose to extend qualified DC, in most cases for reasons
> > and
> > needs very specific to their local projects. The most frequent additional
> > extensions needed seem to be in the form of added encoding schemes.
> >
> > So I'm not sure how successful posting a canonical XSD for qualified DC
> > will
> > be in keeping a lid on the number of XSDs and namespaces used in the OAI
> > universe, and I'm not sure harvesters can count on (or really should ask)
> > providers to export both in their extended qualified DC and a canonical
> > form
> > of qualified DC. Doing so might simplify (slightly) the service providers
> > task, but I'm not sure it's a compelling case, especially from the
> > perspective of the data provider. (A complicating consideration is that
> > any
> > of the above schemas could actually be used by someone who did just have
> > pure qualified DC -- since all augmentations are entirely optional).
> >
> > Hence my suggestion that harvesters, cross-walks, transformations, and
> > other
> > such services might do better to key off of embedded namespaces rather
> > than
> > specific XSD or even top-level namespaces. And though clearly data
> > providers
> > could go out of their way to import qualified DC namespaces into their
> > local
> > XSDs and then not use those namespaces, that seems unlikely -- so I
> > disagree
> > with Simeon that harvesters should steer clear of locally augmented
> > formats
> > based on qualified DC on such an assumption or for fear they won't be able
> > to extract enough useful information from records that maybe do contain
> > additional content in other namespaces. Possibly there's some risk, but it
> > seems to me that a dc:title element or dcterms:created refinement still
> > means much the same whether embedded in a canonical qualified DC record or
> > in a CDP DC augmented qualified DC record.
> >
> > And I don't see why you couldn't write an XSLT to crosswalk from qualified
> > DC to MARC that could be applied not only to records of "pure" qualified
> > DC,
> > but also to OLAC DC or NSDL DC, or CDP DC. Obviously such a generic
> > crosswalk would drop local encoding schemes like olac:linguistic-type,
> > olac:linguistic-field, and nsdl:GEM, and refinements like
> > cdp:holdingInstitutions and cdp:thumbnailIdentifier, but for many purposes
> > that would be okay, especially if the XSLT were smart enough to take
> > advantage of any xs:substitutionGroup information contained in the XSDs
> > referenced by the instances (e.g., so as to know that
> > cdp:thumbnailIdentifier was a refinement of dc:identifier).
> >
> > It may be a little more work, but given the actual trend to date of data
> > providers wanting to augment qualified DC with local semantics, I think
> > we'll need to build our applications smart enough to deal with such
> > diversity. And if we do that, it doesn't really matter if there is a
> > multiplicity of top-level container schemas for qualified DC (as long as
> > they all reference the appropriate DCMI component namespaces).
> >
> > Tim Cole
> > University of Illinois at UC
> >
> > -----Original Message-----
> > From: oai-implementers-bounces at openarchives.org
> > [mailto:oai-implementers-bounces at openarchives.org] On Behalf Of Young,Jeff
> > Sent: Tuesday, August 10, 2004 8:51 AM
> > To: Simeon Warner; oai-implementers at oaisrv.nsdl.cornell.edu
> > Subject: RE: [OAI-implementers] Qualified Dublin Core
> >
> > I agree with Simeon. Lately I've been creating dynamically configured web
> > applications built with distributed independent web services (OAI and SRW
> > in
> > particular). The more schemas and protocols they have in common, the more
> > magic that can happen. DCQ elements hidden behind differing namespace
> > containers and schemas would greatly diminish its value.
> >
> > For example, I am working with Jean Godby on a catalog of XSLT crosswalks
> > (http://errol.oclc.org/schemaTrans.oclc.org.search). Redundant namespaces
> > will only clutter it up and make it harder for people to choose an
> > appropriate crosswalk from a list when then need one.
> >
> > Jeff
> >
> > > -----Original Message-----
> > > From: Simeon Warner [mailto:simeon at cs.cornell.edu]
> > > Sent: Monday, August 09, 2004 7:02 PM
> > > To: oai-implementers at oaisrv.nsdl.cornell.edu
> > > Subject: RE: [OAI-implementers] Qualified Dublin Core
> > >
> > >
> > > I think the problem with "standard elements in any wrapper" approach
> > > is that a harvester has no easy way to know up-front what it might be
> > > getting if it harvests records in a particular format. Harvesting a
> > > metadata format understood to be "only QDC elements" (nothing else, no
> > > funny
> > > business) gives rather more assurance of intelligibility to a
> > > harvester that understands QDC. A canonical schema seems the simplest
> > > way to indicate this (notwithstanding versioning issues mentioned
> > > earlier by Pete Johnston).
> > >
> > > Cheers,
> > > Simeon
> > >
> > > On Mon, 9 Aug 2004, Timothy W. Cole wrote:
> > > > Jeff-
> > > >
> > > > My take is that OAI shouldn't want to get back in business of
> > > > hosting schemas or namespaces for metadata formats. We went to some
> > > > trouble to
> > > get
> > > > away from that when transitioning from 1.1 to 2.0. A blessed
> > > > application namespaces for qualified DC should be left up to the DCMI.
> > > >
> > > > While DCMI decides how they want to handle things (and I know they
> > > > won't
> > > be
> > > > quick), solutions like the one at CCLRC (we've done much the same
> > > > here
> > > for a
> > > > couple of projects) and NSDL are fine. Any namespace-aware OAI
> > > application
> > > > should ignore the locally created namespace and hone in on the dc,
> > > dcterms,
> > > > and dcmitype namespaces and thereby be able to use those elements
> > > without
> > > > any problems. If your OAI service provider respects namespaces, it
> > > shouldn't
> > > > matter what namespace the container element is in -- that's why the
> > > > XML Schemas posted on the DCMI Website were done that way.
> > > >
> > > > Isn't that good enough for harvesting purposes? Are am I missing a
> > > subtle
> > > > consideration that requires a canonical namespace for the container
> > > element?
> > > >
> > > > Tim Cole
> > > > University of Illinois at UC
> > > >
> > > > -----Original Message-----
> > > > From: oai-implementers-bounces at openarchives.org
> > > > [mailto:oai-implementers-bounces at openarchives.org] On Behalf Of
> > > Young,Jeff
> > > > Sent: Monday, August 09, 2004 10:33 AM
> > > > To: Mascord, M (Matthew) ; Young,Jeff;
> > > > oai-implementers at oaisrv.nsdl.cornell.edu
> > > > Cc: LeVan,Ralph; Hickey,Thom
> > > > Subject: RE: [OAI-implementers] Qualified Dublin Core
> > > >
> > > > Yes, this is the problem. Now I have two to choose from. This one,
> > > > and
> > > the
> > > > one created by NSDL. I'm sure there are others out there. For the
> > > > sake
> > > of
> > > > interoperability, it seems to me that the OAI community should bless
> > > (and
> > > > host?) such an "application profile" schema.
> > > >
> > > > Jeff
> > > >
> > > > > -----Original Message-----
> > > > > From: Mascord, M (Matthew) [mailto:M.Mascord at rl.ac.uk]
> > > > > Sent: Monday, August 09, 2004 11:21 AM
> > > > > To: 'Young,Jeff'; oai-implementers at oaisrv.nsdl.cornell.edu
> > > > > Cc: LeVan,Ralph; Hickey,Thom
> > > > > Subject: RE: [OAI-implementers] Qualified Dublin Core
> > > > >
> > > > > Hi -
> > > > >
> > > > > I am the developer of an OAI compatible institutional repository
> > > > > for the UK research council CCLRC.  The URL is
> > http://epubs.cclrc.ac.uk.
> > > > > We are attempting to capture & make publicly accessible any
> > > > > scientific research that has benefitted from the use of CCLRC's
> > > > > facilities or expertise.  We recently went live on the OAI
> > repository
> > network:
> > > > > http://epubs.cclrc.ac.uk/oai?verb=Identify.
> > > > >
> > > > > We provide metadata in both Simple and Qualified Dublin Core but
> > > > > had the same problem as you in finding an authoritative XML schema
> > > > > for Qualified Dublin Core.  In the end we created our own that
> > > > > includes the schema defined at
> > > > > http://dublincore.org/schemas/xmls/qdc/2003/04/02/qualifieddc.xsd
> > > > > and described in the Dublin Core Note at
> > > > > http://dublincore.org/schemas/xmls/qdc/2003/04/02/notes/.  This
> > > > > defines a container element into which elements from the dcterms
> > > > > and dc namespaces may be placed.
> > > > >
> > > > > I'm not sure if this is the best approach so would appreciate any
> > > > > feedback on this.  Our OAI implementation can be tested at
> > > > > http://epubs.cclrc.ac.uk/oaitest.
> > > > >
> > > > > Kind Regards,
> > > > > Matthew Mascord
> > > > > e-Library Software Developer, CCLRC, UK
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: oai-implementers-bounces at openarchives.org
> > > > > > [mailto:oai-implementers-bounces at openarchives.org]On Behalf Of
> > > > > > Young,Jeff
> > > > > > Sent: 09 August 2004 16:03
> > > > > > To: oai-implementers at oaisrv.nsdl.cornell.edu
> > > > > > Cc: LeVan,Ralph; Hickey,Thom
> > > > > > Subject: [OAI-implementers] Qualified Dublin Core
> > > > > >
> > > > > >
> > > > > > I'm looking for an XML Schema for Qualified Dublin Core for use
> > > > > > in OAI repositories. I poked around the UIUC OAI Registry, but
> > > > > > all I found was a couple of ad hoc schemas used by repositories
> > > > > > that appear to be defunct.
> > > > > > Ideally, though, the existence and use of such a schema should
> > > > > > be shared across a broad community and not ad hoc.
> > > > > >
> > > > > > Next, I searched in Google and OAForum but all I found was a
> > > > > > reference to a preliminary effort to establish such a schema
> > > > > > (http://www.ukoln.ac.uk/metadata/dcmi/xmlschema/). This
> > > > > > particular document discusses a sample application schema for a
> > > > > > DCQ container, but the implication is that the final schema must
> > > > > > be decided by the specific application (e.g OAI?). Apparently,
> > > > > > this has never been done.
> > > > > >
> > > > > > Can someone provide some guidance for doing this?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Jeff
> > > > > >
> > > > > > ---
> > > > > > Jeffrey A. Young
> > > > > > Software Architect
> > > > > > Office of Research, Mail Code 710 OCLC Online Computer Library
> > > > > > Center, Inc.
> > > > > > 6565 Frantz Rd.
> > > > > > Dublin, OH 43017-3395
> > > > > > www.oclc.org
> > > > > >
> > > > > > Voice: 614-764-4342
> > > > > > Voice: 800-848-5878, ext. 4342
> > > > > > Fax: 614-718-7477
> > > > > > Email: jyoung at oclc.org
> > > > > >
> > > > > > _______________________________________________
> > > > > > OAI-implementers mailing list
> > > > > > List information, archives, preferences and to unsubscribe:
> > > > > > http://openarchives.org/mailman/listinfo/oai-implementers
> > > > > >
> > > >
> > > > _______________________________________________
> > > > OAI-implementers mailing list
> > > > List information, archives, preferences and to unsubscribe:
> > > > http://openarchives.org/mailman/listinfo/oai-implementers
> > > >
> > > >
> > > > _______________________________________________
> > > > OAI-implementers mailing list
> > > > List information, archives, preferences and to unsubscribe:
> > > > http://openarchives.org/mailman/listinfo/oai-implementers
> > > >
> > >
> > > _______________________________________________
> > > OAI-implementers mailing list
> > > List information, archives, preferences and to unsubscribe:
> > > http://openarchives.org/mailman/listinfo/oai-implementers
> >
> > _______________________________________________
> > OAI-implementers mailing list
> > List information, archives, preferences and to unsubscribe:
> > http://openarchives.org/mailman/listinfo/oai-implementers
>