[OAI-implementers] Qualified Dublin Core

Wed Aug 11 11:34:54 EDT 2004

Hi Rachel,

My feeling is that if someone wants to mix DCQ with other stuff, the
container deserves its own namespace. Otherwise, there is no standard way to
recognize the significance of the mix when the record escapes the confines
of its peculiar context.

I would be simple enough to write an XSLT crosswalk that "dumbs down"
arbitrary XML records to DC or DCQ, but there's a risk that the result would
be a meaningless jumble.

Jeff

> -----Original Message-----
> From: Rachel Heery [mailto:r.heery at ukoln.ac.uk]
> Sent: Wednesday, August 11, 2004 7:24 AM
> To: oai-implementers at oaisrv.nsdl.cornell.edu
> Subject: RE: [OAI-implementers] Qualified Dublin Core
> 
> On Tue, 10 Aug 2004, Timothy W. Cole wrote:
> 
> > 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).
> 
> Seems to me, given the potential that OAI-PMH offers for building
> 'networks of repositories' there are benefits in encouraging applications
> to pass on richest metadata available, ignoring unknown extensions.
> Metadata will be re-harvested by applications that can use extensions.
> 
> Can there be a solution whereby OAI recognises that a single schema
> identified as Qualified Dublin Core might contain local fields? is this
> not analogous to situation in MARC which might contain local fields??
> 
> I have always liked the approach taken in PRISM spec:
> 
> "PRISM-compliant applications MUST NOT throw an error if they encounter
> unknown elements or attributes. They are free to delete or preserve such
> information, although recommended practice is to retain them and pass them
> along. Retaining the information is an architectural principle which helps
> new functionality be established in the presence of older versions of
> software."
> see http://www.prismstandard.org/Pam_1.0/PRISM_1.2h.pdf
> 
> Not sure how far that is achievable with OAI-PMH but it does seem to me to
> recognise the reality of metadata schemas being extended and evolving.
> 
> In addition might there be a barrier in expecting data providers to map
> their 'extended QDC to 'pure QDC' plus 'Simple DC', somewhat going against
> philosophy of OAI trying to make things easy for data providers??
> 
> Rachel
> 
> >
> > 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
> >
> >
> > _______________________________________________
> > OAI-implementers mailing list
> > List information, archives, preferences and to unsubscribe:
> > http://openarchives.org/mailman/listinfo/oai-implementers
> >
> >
> 
> 
> --------------------------------------------------------------------------
> -
> Rachel Heery
> UKOLN, University of Bath                       tel: +44 (0)1225 386724
> http://www.ukoln.ac.uk
> --------------------------------------------------------------------------
> European Conference on Digital Libraries (ECDL 2004),
> Bath, UK, 12-17 September 2004: http://www.ecdl2004.org/
> 
> 
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://openarchives.org/mailman/listinfo/oai-implementers