Robina, and All,
[I'm copying this to dc-libraries because there was a request to include everyone in working groups in discussions. And because I think answers / opinions from others could be helpful.]
Sorry to be so long in replying - no excuse other than the general one of workload...
I'd be willing to draft a short document. But first I need to make sure I understand the problem, especially as I was unable to attend DC2005 so may have missed updates on the original problem as I understood it.
I believe this issue originated from my attempt to produce an XML schema corresponding to the DC-Libraries Application Profile. But it is more fundamental than an XML schema issue (and actually the XML schema will need readdressing when the DC-in-XML Guidelines have been updated).
There are 3 properties within the DC-Lib AP that are taken from MODS: dateCaptured, edition, physicalLocation. Within the hierarchical XML model and structure of MODS the first two are below a container element originInfo and the third is below a container element location. Both container elements are at the 'top' level so can be directly referenced as 'mods:originInfo' and 'mods:location' (where 'mods' is an abbreviation for http://www.loc.gov/mods/v3'), they are only containers (contain no text data), and they also contain further elements.
I believe that there are 2 problems.
Firstly there is the fairly straightforward problem that it is not possible to address these 3 MODS properties directly because they are not at the top level. This problem would be fixed if each of these properties had its own URI. Clearly how those URIs look, ie the scheme they use, is a LoC decision. For the DC-Lib problem a persistent unique URI for each of the three properties is sufficient.
The second problem is more complex - well at least more difficult to explain. MODS is an XML hierarchical model that defines structural relationships between its elements and possibly particular attributes. They are not independent components, nor are they independent of the XML syntax. The element physicalLocation cannot exist independently of its container 'location' element because of the structure defined within the XML schema. To move physicalLocation to the top level would require a drastic redefinition of the XML schema which I doubt is an option - there will already be a lot of people using MODS out there.
On the other hand the DC model is a flat set of (optionally repeatable) properties each with a single value. This corresponds to the RDF model of a set of triples (resource, property, value). DC properties are independent components, with no defined structural relationships. The DC abstract model is also syntax-independent.
The intention in trying to reuse MODS elements in the DC-Lib AP is to make use of components with the right semantics (where appropriate properties are not already available in Dublin Core), which seems a 'good thing' to do.
As I understand it the solution is for LoC to define properties with these semantics as RDF in a persistent location. This would look something similar to the DC property definitions at http://dublincore.org/2005/06/13/dcq . This would define the semantics and URIs for the properties. They could then be used within the DC-Lib AP. It would be sufficient to define only the 3 properties in question - whether LoC decide to define more of them would be their decision. [I think this would also be similar to the way the MARC Relator codes have been defined in RDFS, but probably a standalone document would be more appropriate in this case for just 3 properties, rather than a dynamic transform.]
However, this is really a fix to resolve what is actually more of a political issue, ie. whether to define new DC properties or to 'reuse' MODS ones. The properties that would be defined in this way by RDFS assertions would have the same semantics and names as the MODS XML elements. But they are not really the same objects. But possibly this doesn't matter except to the purists.
There is a further issue with the dateCaptured element. Within MODS it is defined as having an attribute called 'encoding' that captures the value of the encoding scheme. However, I think the above solution of redefining the MODS terms using RDF also resolves that issue. The particular encoding scheme attribute name is not defined by the RDF schema - for an XML encoding it will eventually be defined by the DC-in-XML Guidelines.
Hopefully I have stated this problem correctly and am not completely off beam. If so it should make a starting point for the proposed document. I'm not sure if I described the situation in 'language all could understand' though...
A further thought. I believe that the Collection Description WG are proposing a property cld:isLocatedAt. I think the semantics of this are very similar to DC-Lib's physicalLocation. Would another option be for DC-Lib to use the cld property in this case?
Best wishes,
Ann
-------------------------------------------------
Ann Apps. IT Specialist (Research & Development), MIMAS,
The University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039 Fax: +44 (0) 161 275 6040
Email: [log in to unmask] WWW: http://epub.mimas.ac.uk/ann.html
--------------------------------------------------
> -----Original Message-----
> From: Clayphan, Robina [mailto:[log in to unmask]]
> Sent: Tuesday, February 14, 2006 4:57 PM
> To: Corey Harper; [log in to unmask]; Ian Davis
> Cc: [log in to unmask]
> Subject: Progressing DC-Lib and MODS
>
> Dear All,
>
> You may remember that back in September you all volunteered to take part
> in a small group to progress the issue of re-using MODS elements in
> DC-Lib. I hope you are still willing to do so as I have a request to
> make.
>
> The first task of this group as I see it is to articulate the problem in
> language all could understand so we could be clear as to how to tackle
> it and be able to explain it.
>
> Rebecca Guenther (Library of Congress) is already investigating the two
> things she believes they need to do to MODS to solve the problem on the
> basis of her understanding. These two actions are:
>
> 1. the best way to make MODS elements global (that are subelements
> under something else, which all of the MODS elements used in the LAP
> are).
>
> 2. Defining URIs for MODS elements (more complicated because it
> involves some policy decisions that we need to be ready to make). The
> approval of info: as a URI scheme might help this decision making
> process.
>
> I believe these to be correct and Rebecca would welcome confirmation
> from this group as a whole. Apart from email discussion and
> confirmation I should like to produce a document (as indicated above as
> our first task) as the means to do this. Would one of you be willing to
> write a draft in the first instance?
>
> Regards,
> Robina
>
> **************************************************************************
>
> Experience the British Library online at www.bl.uk
>
> Help the British Library conserve the world's knowledge. Adopt a Book.
> www.bl.uk/adoptabook
>
> The Library's St Pancras site is WiFI - enabled
>
> **************************************************************************
>
> The information contained in this e-mail is confidential and may be legally
> privileged. It is intended for the addressee(s) only. If you are not the intended
> recipient, please delete this e-mail and notify the [log in to unmask] : The contents
> of this e-mail must not be disclosed or copied without the sender's consent.
>
> The statements and opinions expressed in this message are those of the author
> and do not necessarily reflect those of the British Library. The British Library does
> not take any responsibility for the views of the author.
>
> **************************************************************************
>
|
