[UPS] Open Archive metadata set DTD

[Mark Doyle]

--Apple-Mail-1285633588-1
content-type: text/enriched; charset=us-ascii
content-transfer-encoding: quoted-printable

<fontfamily><param>Helvetica</param>> From: Carl Lagoze =
<<lagoze@cs.cornell.edu>=20

> Date: 1999-12-20 15:20:41 -0500=20


> I finally got a chance to look at the DTD and I think its got a hole =
in it.=20

> You have author with simply PCData but as spec'ed its structured - =
name and=20

> organization.=20


New DTD and example attached with <<name> and <<organization> added. =
Example now has namespace declaration in the wrapper <<oams> element. =
Elements with this tag thus default to having oams: as a prefix. Thus, =
this minimal metadata set can be embedded in a larger DTD for those who =
want to export more than just the core. That way they can be =
interoperable, but not contstrained by the DTD. After a discussion, Carl =
and I came to the understanding that this is more desirable than =
building extensibility into the DTD itself. Also, I left out the <<p> =
element for multi-paragraph abstracts. Whitespace hints are enough here =
- the idea is be oriented more towards indexing than displaying. The =
DIENST protocol and alternative, richer metadata formats can be used to =
exchange more detailed information if desired.


I mapped the oams: namespace to the URI =
'http://www.OpenArchives.org/OAMS/' - is that OK? There is no =
requirement that this resolve to a real URL, but it might be a good =
idea. Note that these things are strictly case-sensitive - is this =
choice OK?


Happy 1900 everyone.


Mark


</fontfamily>=

--Apple-Mail-1285633588-1
content-type: application/octet-stream; x-unix-mode=0644; name=oams.dtd
content-transfer-encoding: 7bit

<!-- Open Archives Metadata Set (OAMS) -->
<!-- This DTD can be used to represent the elements of the
     Open Archives Metadata Set-->
    
<!-- Draft version 0.2, Mark Doyle Dec 27, 1999 -->

<!-- Questions: What entity sets should we use?
                Create an OAMS namespace?
-->

<!-- Dates are to be in encoded using the "Complete Date" variant of
     ISO8601-->

<!ENTITY % doctype "oams">

<!ELEMENT %doctype; (title, accession, displayId*, fullId, author+,
                     abstract?,subject*,comment*,discovery)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT accession EMPTY>
<!ATTLIST accession date CDATA #REQUIRED>

<!ELEMENT displayId (#PCDATA)>

<!ELEMENT fullId (#PCDATA)>

<!ELEMENT author (name,organization*)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT organization (#PCDATA)>

<!ELEMENT abstract (#PCDATA)>

<!ELEMENT subject (#PCDATA)>

<!ELEMENT comment (#PCDATA)>

<!ELEMENT discovery EMPTY>
<!ATTLIST discovery date CDATA #REQUIRED>

<!-- ENTITY sets - lifted from MathML DTD -->
<!-- ISO 9573-13 -->
<!ENTITY % ent-isoamsa SYSTEM "isoamsa.ent" >
%ent-isoamsa;
<!ENTITY % ent-isoamsb SYSTEM "isoamsb.ent" >
%ent-isoamsb;
<!ENTITY % ent-isoamsc SYSTEM "isoamsc.ent" >
%ent-isoamsc;
<!ENTITY % ent-isoamsn SYSTEM "isoamsn.ent" >
%ent-isoamsn;
<!ENTITY % ent-isoamso SYSTEM "isoamso.ent" >
%ent-isoamso;
<!ENTITY % ent-isoamsr SYSTEM "isoamsr.ent" >
%ent-isoamsr;
<!ENTITY % ent-isogrk3 SYSTEM "isogrk3.ent" >
%ent-isogrk3;
<!ENTITY % ent-isogrk4 SYSTEM "isogrk4.ent" >
%ent-isogrk4;
<!ENTITY % ent-isomfrk SYSTEM "isomfrk.ent" >
%ent-isomfrk;
<!ENTITY % ent-isomopf SYSTEM "isomopf.ent" >
%ent-isomopf;
<!ENTITY % ent-isomscr SYSTEM "isomscr.ent" >
%ent-isomscr;
<!ENTITY % ent-isotech SYSTEM "isotech.ent" >
%ent-isotech;
<!-- ISO 8879 -->
<!ENTITY % ent-isobox SYSTEM "isobox.ent" >
%ent-isobox;
<!ENTITY % ent-isocyr1 SYSTEM "isocyr1.ent" >
%ent-isocyr1;
<!ENTITY % ent-isocyr2 SYSTEM "isocyr2.ent" >
%ent-isocyr2;
<!ENTITY % ent-isodia SYSTEM "isodia.ent" >
%ent-isodia;
<!ENTITY % ent-isogrk1 SYSTEM "isogrk1.ent" >
%ent-isogrk1;
<!ENTITY % ent-isogrk2 SYSTEM "isogrk2.ent" >
%ent-isogrk2;
<!ENTITY % ent-isolat1 SYSTEM "isolat1.ent" >
%ent-isolat1;
<!ENTITY % ent-isolat2 SYSTEM "isolat2.ent" >
%ent-isolat2;
<!ENTITY % ent-isonum SYSTEM "isonum.ent" >
%ent-isonum;
<!ENTITY % ent-isopub SYSTEM "isopub.ent" >
%ent-isopub;
<!-- MathML aliases for characters defined above -->
<!ENTITY % ent-mmlalias SYSTEM "mmlalias.ent" >
%ent-mmlalias;
<!-- MathML new characters -->
<!ENTITY % ent-mmlextra SYSTEM "mmlextra.ent" >
%ent-mmlextra;
<!-- end of ENTITY sets -->

--Apple-Mail-1285633588-1
content-type: application/octet-stream; x-unix-mode=0644; name=test.xml
content-transfer-encoding: quoted-printable

<?xml version=3D"1.0"?>
<!DOCTYPE oams SYSTEM "oams.dtd">
<oams xmlns=3D'http://www.OpenArchives.org/OAMS/'>
<title>Dilaton Contact Terms in the Bosonic and Heterotic
Strings</title>
<accession date=3D"1992-01-30"/>
<displayId>http://arXiv.org/abs/hep-th/9201076</displayId>
<fullId>arXiv:hep-th/9201076</fullId>
<author><name>Mark Doyle</name><organization>Princeton =
University</organization></author>
<abstract>Dilaton contact terms in the bosonic and heterotic strings are =
examined following the recent work of Distler and Nelson on the bosonic =
and semirigid strings. In the bosonic case dilaton two-point functions =
on the sphere are calculated as a stepping stone to constructing a good =
coordinate family for dilaton calculations on higher genus surfaces. It =
is found that dilaton-dilaton contact terms are improperly normalized, =
suggesting that the interpretation of the
dilaton as the first variation of string coupling breaks down when other =
dilatons are present. It seems likely that this can be attributed to the =
tachyon divergence found in Ref 1. For the heterotic case, it is found =
that there is no tachyon divergence and that the dilaton contact terms =
are properly normalized. Thus, a dilaton equation analogous to the one =
in topological gravity is derived and the interpretation of the dilaton =
as the string coupling constant goes through.</abstract>
<subject>High Energy Physics - Theory</subject>
<comment>Journal-ref: Nucl. Phys. B381 (1992) 158-200</comment>
<discovery date=3D"1999-12-06"/>
</oams>

--Apple-Mail-1285633588-1--