[AMF-talk] schemaLocation

Thomas Krichel amf-talk@lists.openlib.org
Wed, 7 Aug 2002 00:23:02 -0500


  Simeon Warner writes
> 
> Schema at
>   http://amf.openlib.org/2001/amf.xsd
> now validates with XSV and I think the elements matche the current 
> (incorrectly dated 2001-09-01) version of ebisu.

  I have now dated it to the datestamp on my ebisu.yo on trabbi.
  2002-07-01

> There are a number of places where the value restrictions are not as
> tight as ebisu.

  I will examine the schema a bit later. 


> I see there have been quite a few changes and I have attempted to work
> through them all.
> 
> In text/serial, why change <title> to <journaltitle> when it is the
> equivalent of <OpenURL:title>? Seems better to just say <title> and
> <stitle> as used within OpenURL. Similary for your change to <issuedate>
> instead of <date> (and cf <OpenURL:date>). In this section I think we
> should use all the OpenURL element names even if we just import all the
> types into our own namespace.

  We decided, or at least I think we did, to use the vocabulary
  by Ann, the proposal of the DC-citation working group, effectively
  her work. It has little chance of becoming the law of DC, but we 
  decided to use it, so I changed some of the element names in
  the serial section. I don't like the openurl names because
  they are cryptic.

> I see issupervisorof has been added in several places, what is the
> motivation for that?

  It has been there for a while. 

  Could be used for dissertation, and I think it was there for a 
  while. Trouble is that in the US the supervisor is called the
  advisor. We in RePEc have no use for it. Remove?

> 
> I'm still thinking about what it means to claim elements are equivalent to
> various things in other schemas/schemes and then use them within a
> different namespace

  on that issue, I think we are talking about a semantic equivalence
  here, and maybe that should be explicitly stated in the draft?

> and further qualify them with attributes. I am worried
> that we are producing something that will be too complex to use correctly.

  I am not so worried about that, but if you have concrete things
  I would be happy to make changes. 

> 
> However, what we need now are some instance documents, preferably real
> exmaples of how we intend to use this. I will try to come up with a few
> and would welcome others...

  For the documentation?

  I think what is most needed is to have running implementations
  that are solid, and the amf2oai_dc.xsl. If we have an
  implenentation at arXiv plus that file ready for the Geneva
  meeting that would be good. Will you guys attend?


  Cheers,

  Thomas Krichel                                   mailto:krichel@openlib.org
                                              http://openlib.org/home/krichel
                                          RePEc:per:1965-06-05:thomas_krichel