Yes, I guess assigning URIs to elements is another issue, and one that we
haven't clearly worked out, nor do we completely understand yet. I was
told that the point of it was to be able to do just this, reuse elements,
but I realize now that there are some technical issues that need to be
addressed in the schema itself. And you are right, there is no commitment
to getting something at the other end when you use that element URI
(ideally it would be some documentation about it). We need to take that
issue separately.
I agree that it is worth doing something about this in the schema, and Ray
is going to send a message to the list about it. In any case, we would
need to do something because the DC-Library Application Profile uses some
MODS elements. At some point when that is completed someone will write a
schema for it and will need to use a few MODS elements (location and
edition).
Rebecca
On Thu, 6 Nov 2003, Robin Wendler wrote:
> Hi, Rebecca --
> As others have pointed out for me (thank you!), I need to be able to
> use the "ref" attribute of XML or another mechanism to say within
> an XML schema that a particular element from MODS is to be considered
> valid, and in such a way that a standard XML parser could determine if an
> instance document with that element is valid.
>
> "Ref" must point to a global element in the target namespace. If an element-
> level URI can help me do that, I do not know how. And from what I remember
> of CORES, there wasn't any expectation that the URIs would be actionable.
> Thus, even if XML schema provided the mechanism to use them to invoke an
> element definition, which I don't think it does, there's no guarantee that
> anything would be on the other end, or that if there was something that it
> would be machine-interpretable.
>
> As you know, I love that fact that MODS enables element hierarchy. What I
> am suggesting would not get rid of that. It would, however, enable the use of
> individual components such as edition, frequency, etc. in other schemas
> without requiring that they enable the entire, for example, originInfo element.
> originInfo is the most compelling case I see in MODS. That groups several
> things which do not depend on the context of their parent to be meaningful.
> In contrast, the subelements of name are not independent characteristics.
> This might be an unacceptable can of worms, but I think it's worth looking
> into.
>
> --Robin
>
> At 05:29 PM 11/5/2003 -0500, you wrote:
> >Robin:
> >
> >There may be some technicalities with XML schema that makes this true that
> >I don't know. But I thought that the real issue is whether you can
> >identify a metadata element with a URI. If you can, then you could use it
> >in another schema. We have been involved in an agreement (CORES) to
> >provide URIs for our metadata elements. This would apply to MARC elements
> >as well as MODS element. For the moment, we would start with giving a
> >policy for assignment of persistent URIs for elements. In the future, we
> >would mark up our documentation explicitly using these URIs for the
> >elements. So, in fact, there are MODS elements that are used in the
> >DC-Library application profile for the reasons you suggested: that they
> >are metadata elements already defined and just as though they can be
> >referenced with a URI they could theoretically be used.
> >
> >The article in D-Lib magazine is:
> >http://www.dlib.org/dlib/july03/baker/07baker.html
> >In the article it gives some examples of likely assignments. One is:
> >http://www.loc.gov/mods/originInfo.edition
> >So we've used this convention to refer to a subelement.
> >
> >The elements in the DC-Library application profile that are referenced
> >are:
> >originInfo/dateCaptured
> >location
> >(I admit, there is yet no schema for DC-Lib AP.)
> >
> >In the case of Dublin Core, the documentation does assign URIs for
> >elements, which I think is the reason they can be used globally. In any
> >case, Dublin Core is flat and there is no hierarchy in the elements, which
> >is another reason why all the elements are "global". The hierarchy in MODS
> >is not something we would want to drop.
> >
> >We do have some further work to do to make all this implementable. But I
> >do think the important thing is the ability to reference the element-- and
> >then you would include the namespace of course in any instance or schema
> >that uses the MODS elements.
> >
> >Rebecca
> >
> >
> >On Wed, 5 Nov 2003, Robin Wendler wrote:
> >
> > > Could I beg for a little Schema for Dummies advice?
> > >
> > > Did the MODS schema authors consider making more of
> > > the MODS subelements global elements, and "ref-ing" them
> > > within the larger elements such as originInfo?
> > >
> > > The reason I ask is that in trying to draft an Eresources Management
> > > schema for the DLF ERM Initiative, I would prefer to incorporate
> > > MODS elements rather than define brand new ones where there is overlap.
> > > Unfortunately, XML schema only permits the referencing of global elements,
> > > when what the ERM data dictionary calls for correspond to subelements of
> > > MODS such as publisher and frequency. For example, ERM doesn't
> > > need "place", but I do want to be able to specify which pieces of
> > originInfo
> > > ERM records should use. I can't even "ref" originInfo, either because it is
> > > not global, is a complexType or both. (I wonder if the xlink and Dublin
> > Core
> > > schemas were created the way they were expressly to facilitate the reuse of
> > > their elements in other schemas.)
> > >
> > > Is there another technique that would permit the use of specific MODS
> > > subelements within another schema? The concepts I want are in MODS, but
> > > I haven't found a way to use them.
> > >
> > > The usual apologies for asking dumb questions apply. Thanks,
> > >
> > > --Robin
> > >
> > > Robin Wendler
> > > Harvard University Library
> > > Office for Information Systems
> > > 1280 Massachusetts Ave., Suite 404
> > > Cambridge, MA 02138 USA
> > > 617-495-3724 (W)
> > > 617-495-0491 (F)
> > > [log in to unmask]
>
