JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-LIBRARIES Archives


DC-LIBRARIES Archives

DC-LIBRARIES Archives


DC-LIBRARIES@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-LIBRARIES Home

DC-LIBRARIES Home

DC-LIBRARIES  February 2005

DC-LIBRARIES February 2005

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: XML schema

From:

Andy Powell <[log in to unmask]>

Reply-To:

DC-Libraries Working Group <[log in to unmask]>

Date:

Wed, 9 Feb 2005 23:59:49 +0000

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (96 lines)

On Wed, 9 Feb 2005, Ray Denenberg, Library of Congress wrote:

> From: "Ann Apps" <[log in to unmask]>
> > The way of encoding these MODS terms is different from, and not
> > really consistent with, DC practice to date. They have to include
> > nested elements, eg:
> >
> > <mods:location>
> >   <mods:url>http://example.org/myurl</mods:url>
> > <mods:location>
>
>  Hi Ann,
>
> I'm not really up-to-date with dc so I don't know what  dc practice you're
> referring to,

The fundamental problem here is that the XML encoding of DC is a
representation of the underlying DC 'model' (the DCMI Abstract Model)
which essentially is the same 'resource, property, value' triple model
found in RDF.  MODS (in common with many other XML-based languages, e.g.
LOM, METS, etc.) does not share that same underlying model.

This is not a critisism of any of these other XML-based languages BTW -
just a statement of fact.

It is therefore not possible to simply squish together DC 'elements' and
MODS 'elements' in any kind of meangingful way.

Even if, as you suggest below, there is a way to make mods:url look
superficially like a DC 'element' (i.e. to use it without the nesting),
unless it really is a DC-compatible property, then what is being attempted
here simply does *not* work.

By "DC-compatible property" I mean that the URI
http://www.loc.gov/mods/v3url (*)  identifies a 'property' (as defined in
section 7 of the DCMI Abstract Model) that is intended to be used in the
context of the DC Abstract Model and/or RDF.  And, as a rule of thumb, I'd
suggest this means that the semantics of this property should be declared
using RDFS (as per all the current DC terms).

(*) Note the rather odd URI here caused by the mods namespace URI not
ending in either a slash or a hash - I hope I've got this right.   If not,
apologies.

Andy.

> but it you want to be able to use
> <mods:url>http://example.org/myurl</mods:url>
> without wrapping it in <mods:location>, there's an easy way.
>
> The mads schema has the same problem, so we've created a "mods-for-mads"
> schema. It's totally compatible with the current mods (they produce
> identical instance sets) but a number of new data types have been created
> (url one of them) so that they can be directly referenced.
>
> Take a look at
> http://www.loc.gov/standards/mads/mads-preliminary-draft-2-dec-17.xsd
>
> It references mods url as:
> <xsd:element name="url" type="mods:urlType" .....
>
> And look at
> http://www.loc.gov/standards/mads/mods-for-mads.xsd
>
> It declares element <url> within <location> as
> <xsd:element name="url" type="urlType" minOccurs="0" maxOccurs="unbounded"
> />
> and creates a new definition urlType.
>
> So you could reference it as mods:url,   You'd just need to change the
> schema location:
> <xsd:import namespace="http://www.loc.gov/mods/v3"
> schemaLocation="http://www.loc.gov/standards/mads/mods-for-mads.xsd" />
>
> Mads is still a draft.  Our intention is to issue a new mods version (3.1)
> that includes these definitions, sometime after (or when) we release the
> first version of mads.
>
> We would be happy to include any other similar definitions in mods 3.1, if
> it makes sense to. (It was once suggested that we should treat every mods
> subelement in this fashion.  I'm fairly sure we don't want to do that,
> because (1) it doesn't make sense in every case, and (2) it would create a
> much-less-readable schema.)  For example, edition and dateCaptured of
> originInfo.  If you'd like I'll change mods-for-mads so that these can be
> referenced (even though mads doesn't reference them currently) or any
> others.
>
> --Ray
>

Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell/      +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
July 2016
June 2016
May 2016
April 2016
March 2016
January 2016
December 2015
October 2015
June 2015
May 2015
March 2015
September 2014
July 2014
June 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
December 2012
November 2012
September 2012
August 2012
March 2012
February 2012
November 2011
October 2011
September 2011
July 2011
June 2011
January 2011
November 2010
October 2010
September 2010
August 2010
June 2010
May 2010
April 2010
March 2010
February 2010
October 2009
September 2009
June 2009
May 2009
March 2009
February 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
October 2007
September 2007
August 2007
July 2007
June 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
December 2005
November 2005
October 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
April 2004
March 2004
February 2004
December 2003
November 2003
October 2003
September 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
November 2002
October 2002
September 2002
July 2002
May 2002
April 2002
March 2002
January 2002
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
July 2000
June 2000
April 2000
March 2000
February 2000
January 2000
December 1999


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager