[OAI-implementers] ListMetadataFormats problem
Mick Bass
bass@MIT.EDU
Wed, 31 Jan 2001 11:48:19 -0500
--=====================_149350594==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Mick Bass here, from HP (employer) and MIT (partner & development site),
leading DSpace joint development effort <http://www.dspace.org>.
I'm rather uninitiated in the ways of XML-Schema (but aren't we
all...). So take these comments only as potentially helpful...
import would seemingly allow validation of DC elements as a part of a
schema in another namespace.
It sounds like in addition to this you want to extend DC to include new
elements, though, so I'd also recommend a read of the tutorial section on
"Derving complex types by extension":
<http://www.w3.org/TR/xmlschema-0/#DerivExt>:
>4.2 Deriving Types by Extension
>To create our address constructs, we start by creating a complex type
>called Address in the usual way (see address.xsd). The Address type
>contains the basic elements of an address: a name, a street and a city.
>(Such a definition will not work for all countries, but it will serve the
>purposes of our example.) From this starting point we derive two new
>complex types that contain all the elements of the original type plus
>additional elements that are specific to addresses in the US and the UK.
>The technique we use here to derive new (complex) address types by
>extending an existing type is the same technique we used in in Section
>2.5.1, except that our base type here is a complex type whereas our base
>type in the previous section was a simple type.
>We define the two new complex types, USAddress and UKAddress, using the
>complexType element. In addition, we indicate that the content models of
>the new types are complex, i.e. contain elements, by using the
>complexContent element, and we indicate that we are extending the base
>type Address by the value of the base attribute on the extension element.
>When a complex type is derived by extension, its effective content model
>is the content model of the base type plus the content model specified in
>the type derivation. Furthermore, the two content models are treated as
>two children of a sequential group. In the case of UKAddress, the content
>model of UKAddress is the content model of Address plus the declarations
>for a postcode element and an exportCode attribute.
The dublincore schema at http://www.openarchives.org/OAI/dc.xsd defines:
<element name="dc" type="dc:dublincoreType"/>
<complexType name="dublincoreType">
<choice minOccurs="0" maxOccurs="unbounded">
<element name="title" minOccurs="0" maxOccurs="unbounded" type="string"/>
<element name="creator" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="subject" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="description" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="contributor" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="publisher" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="date" minOccurs="0" maxOccurs="unbounded" type="string"/>
<element name="type" minOccurs="0" maxOccurs="unbounded" type="string"/>
<element name="format" minOccurs="0" maxOccurs="unbounded" type="string"/>
<element name="identifier" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="source" minOccurs="0" maxOccurs="unbounded" type="string"/>
<element name="language" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="relation" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="coverage" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="rights" minOccurs="0" maxOccurs="unbounded" type="string"/>
</choice>
</complexType>
You may want something like:
<element name="edc" type="edc:extendedDublincoreType"/>
<complexType name="extendedDublincoreType">
<complexContent>
<extension base="dc:dublincoreType">
<sequence>
<element name="shoesize" minOccurs="0" maxOccurs="unbounded"
type="string"/>
<element name="numfeet" minOccurs="0" maxOccurs="unbounded"
type="positiveInteger"/>
</sequence>
</extension>
</complexContent>
</complexType>
I'm thinking this would be defined in your namespace (here, "edc"), but the
dc namespace would need to be imported so that the validation processor
would be aware of the definition of dublincoreType, so that your extension
could be validated.
If this were to work, you ought to be able to declare instance metadata of
type ExtendedDublinCoreType (in namespace "edc"), and have it be
successfully validated in schemas expecting straight up DublinCore. The
details of actually getting this to work, I leave to you, but this seems to
be their intent from a read through the XML-Schema documentation :)
The impact on harvesters of instance metadata exported using types derived
by extension is not yet clear to me...
- Mick
At 07:15 AM 1/31/01 -0500, you wrote:
>Jeff, I think you've got the wrong approach here. Having spent the last
>hour or so staring at the xml schema primer at
>http://www.w3.org/TR/xmlschema-0 I found the explanation on importing
>types at http://www.w3.org/TR/xmlschema-0/#import. Using this mechanism
>you can pull in types (elements) from another namespace. E.g., you
>could define a schema carlmeta.xsd with a target namespace
>http://foo.org/carlmeta with an import of
>http://purl.org/dc/elements/1.1. I quote the primer:
>
>When schema components are imported from multiple namespaces, each
>namespace must be identified with a separate import element. The import
>elements themselves must appear as the first children of the schema
>element. Furthermore, each namespace must be associated with a prefix,
>using a standard namespace declaration, and that prefix is used to
>qualify references to any schema components belonging to that namespace.
>Finally, import elements optionally contain a schemaLocation attribute
>to help locate resources associated with the namespaces.
>
>Don't have time now to experiment with this but coming up with an
>example shouldn't be too hard.
>
>Carl
>
> > -----Original Message-----
> > From: Young,Jeff [mailto:jyoung@oclc.org]
> > Sent: Tuesday, January 30, 2001 4:58 PM
> > To: 'lagoze@cs.cornell.edu'
> > Subject: FW: [OAI-implementers] ListMetadataFormats problem
> >
> >
> > Hi Carl,
> >
> > I don't think things are as simple as I'd hoped. I want to
> > check with you
> > first, though, before I stir up more confusion in the
> > listserv. Apparently,
> > the xsi:schemaLocation element expects namespaces to be
> > paired with schema
> > locations. If this is true, then a single schema won't work for the
> > application I described below. Is there any reason that
> > schemas can't be
> > repeatable as well as namespaces in relation to metadata formats?
> >
> > Jeff
> >
> > > -----Original Message-----
> > > From: Young,Jeff [mailto:jyoung@oclc.org]
> > > Sent: Tuesday, January 30, 2001 4:01 PM
> > > To: 'OAI-implementers'
> > > Subject: [OAI-implementers] ListMetadataFormats problem
> > >
> > >
> > > I'm working on an OAI repository for a group that wants to
> > > define it's own
> > > metadata format. The trick is, this format will be a
> > > combination of Dublin
> > > Core elements and some new elements yet to be defined. The
> > > examples in the
> > > OAI specs, however, all assume that the metadata will consist
> > > of elements
> > > from a single namespace. I believe, for the most part, that
> > > the OAI spec
> > > doesn't preclude the use of multiple namespaces. For example,
> > > I imagine that
> > > the following XML fragment is likely to be acceptable:
> > >
> > > <combined xmlns:dc="http://purl.org/dc/elements/1.1/"
> > > xmlns:myelems="http://www.myelems.com/"
> > > xmlns:xsi="..."
> > > xsi:schemaLocation="http://purl.org/dc/elements/1.1/
> > > http://www.myelems.com/
> > > http://www.myelems.com/combined.xsd">
> > > <dc:title>This is the title</dc:title>
> > > <myelems:shoesize>12</myelems:shoesize>
> > > </combined>
> > >
> > > (As far as I can tell, specifying multiple namespaces in the
> > > xsi:schemaLocation attribute is perfectly valid.)
> > >
> > > Assuming no one sees any problems with this, I do think I see
> > > a problem with
> > > ListMetadataFormats.xsd. Now that multiple namespaces are
> > > involved, I expect
> > > that ListMetadataFormats will need to accommodate them with multiple
> > > metadataNamespace elements. The XML schema for
> > > ListMetadataFormats, however,
> > > sets the maxOccurs for metadataNamespace to one. I suspect
> > > this is easily
> > > changed to unbounded.
> > >
> > > Hopefully, the problem is no more involved than this, but
> > > someone may want
> > > to check my assumptions.
> > >
> > > Thanks,
> > > Jeff
> > >
> > > ---
> > > Jeffrey A. Young
> > > Senior Consulting Systems Analyst
> > > Office of Research, Mail Code 710
> > > OCLC Online Computer Library Center, Inc.
> > > 6565 Frantz Road
> > > Dublin, OH 43017-3395
> > > www.oclc.org
> > >
> > > Voice: 614-764-4342
> > > Fax: 614-764-2344
> > > Email: jyoung@oclc.org
> > >
> > >
> > >
> > > _______________________________________________
> > > OAI-implementers mailing list
> > > OAI-implementers@oaisrv.nsdl.cornell.edu
> > > http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> > >
> >
>_______________________________________________
>OAI-implementers mailing list
>OAI-implementers@oaisrv.nsdl.cornell.edu
>http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
=========================
Mick Bass, Sloan MOT 2000
R&D Project Manager
Hewlett-Packard Company
Cambridge, MA
617.253.6617 office
617.899.3938 mobile
617.452.3000 fax
617.627.9694 residence
bass@alum.mit.edu
mick_bass@hp.com
=========================
--=====================_149350594==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
Mick Bass here, from HP (employer) and MIT (partner & development
site), leading DSpace joint development effort
<<a href=3D"http://www.dspace.org/"=
eudora=3D"autourl">http://www.dspace.</a><a href=3D"http://www.dspace.org/"=
eudora=3D"autourl">org</a>>.<br>
<br>
I'm rather uninitiated in the ways of XML-Schema (but aren't we
all...). So take these comments only as potentially=20
helpful...<br>
<br>
import would seemingly allow validation of DC elements as a part of a
schema in another namespace. <br>
<br>
It sounds like in addition to this you want to extend DC to include new
elements, though, so I'd also recommend a read of the tutorial section on
"Derving complex types by extension":<br>
<br>
<<a href=3D"http://www.w3.org/TR/xmlschema-0/#DerivExt"=
eudora=3D"autourl">http://www.w3.org/TR/xmlschema-0/#DerivExt</a>>:<br>
<br>
<blockquote type=3Dcite cite><font size=3D5><b>4.2 Deriving Types by
Extension <br>
</b></font>To create our address constructs, we start by creating a
complex type called
<font face=3D"Courier New, Courier" size=3D4>Address</font><font=
face=3D"Courier New, Courier">
in the usual way (see </font><font face=3D"Courier New, Courier" size=3D4=
color=3D"#0000FF"><u>address.xsd</u></font><font face=3D"Courier New,=
Courier">). The </font><font face=3D"Courier New, Courier"=
size=3D4>Address</font><font face=3D"Courier New, Courier"> type contains=
the basic elements of an address: a name, a street and a city. (Such a=
definition will not work for all countries, but it will serve the purposes=
of our example.) From this starting point we derive two new complex types=
that contain all the elements of the original type plus additional elements=
that are specific to addresses in the US and the UK. The technique we use=
here to derive new (complex) address types by extending an existing type is=
the same technique we used in in </font><font color=3D"#0000FF"><u>Section=
2.5.1</u></font><font face=3D"Courier New, Courier">, except that our base=
type here is a complex type whereas our base type in the previous section=
was a simple type. <br>
</font>We define the two new complex types, <font face=3D"Courier New,=
Courier" size=3D4>USAddress</font><font face=3D"Courier New, Courier"> and=
</font><font face=3D"Courier New, Courier" size=3D4>UKAddress</font><font=
face=3D"Courier New, Courier">, using the </font><font face=3D"Courier New,=
Courier" size=3D4 color=3D"#0000FF"><u>complexType</u></font><font=
face=3D"Courier New, Courier"> element. In addition, we indicate that the=
content models of the new types are complex, i.e. contain elements, by=
using the </font><font face=3D"Courier New, Courier" size=3D4=
color=3D"#0000FF"><u>complexContent</u></font><font face=3D"Courier New,=
Courier"> element, and we indicate that we are extending the base type=
</font><font face=3D"Courier New, Courier" size=3D4>Address</font><font=
face=3D"Courier New, Courier"> by the value of the </font><font=
face=3D"Courier New, Courier" size=3D4=
color=3D"#0000FF"><u>base</u></font><font face=3D"Courier New, Courier">=
attribute on the </font><font face=3D"Courier New, Courier" size=3D4=
color=3D"#0000FF"><u>extension</u></font><font face=3D"Courier New,=
Courier"> element. <br>
</font>When a complex type is derived by extension, its effective content=
model is the content model of the base type plus the content model=
specified in the type derivation. Furthermore, the two content models are=
treated as two children of a sequential group. In the case of <font=
face=3D"Courier New, Courier" size=3D4>UKAddress</font><font face=3D"Courie=
r New, Courier">, the content model of </font><font face=3D"Courier New,=
Courier" size=3D4>UKAddress</font><font face=3D"Courier New, Courier"> is=
the content model of </font><font face=3D"Courier New, Courier"=
size=3D4>Address</font><font face=3D"Courier New, Courier"> plus the=
declarations for a </font><font face=3D"Courier New, Courier"=
size=3D4>postcode</font><font face=3D"Courier New, Courier"> element and an=
</font><font face=3D"Courier New, Courier" size=3D4>exportCode</font><font=
face=3D"Courier New, Courier"> attribute. </font></blockquote><br>
The dublincore schema at <a href=3D"http://www.openarchives.org/OAI/dc.xsd"=
eudora=3D"autourl">http://www.openarchives.org/OAI/dc.xsd</a> defines:<br>
<br>
<font face=3D"Fixedsys" size=3D1><element name=3D"dc"=
type=3D"dc:dublincoreType"/><br>
<br>
<complexType name=3D"dublincoreType"><br>
<choice minOccurs=3D"0"=
maxOccurs=3D"unbounded"><br>
<element name=3D"title" minOccurs=3D"0"=
maxOccurs=3D"unbounded" type=3D"string"/><br>
<element name=3D"creator" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"subject" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"description" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"contributor" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"publisher" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"date" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"type" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"format" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"identifier" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"source" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"language" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"relation" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"coverage" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
<element name=3D"rights" =
minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/><br>
</choice><br>
</complexType><br>
<br>
</font>You may want something like:<br>
<br>
<font face=3D"Fixedsys" size=3D1><element name=3D"edc"=
type=3D"edc:extendedDublincoreType"/><br>
<br>
</font><font face=3D"Fixedsys"><complexType=
name=3D"extendedDublincoreType"> <br>
<complexContent> <br>
<extension base=3D"dc:dublincoreType">=
<br>
<sequence> <br>
<element=
name=3D"shoesize" </font><font face=3D"Fixedsys"=
size=3D1>minOccurs=3D"0" maxOccurs=3D"unbounded"=
type=3D"string"/</font><font face=3D"Fixedsys">> <br>
<element=
name=3D"numfeet" </font><font face=3D"Fixedsys"=
size=3D1>minOccurs=3D"0" maxOccurs=3D"unbounded"=
</font><font face=3D"Fixedsys">type=3D"positiveInteger"/> <br>
</sequence> <br>
</extension> <br>
</complexContent> <br>
</complexType> <br>
<br>
</font>I'm thinking this would be defined in your namespace (here,=
"edc"), but the dc namespace would need to be imported so that=
the validation processor would be aware of the definition of=
dublincoreType, so that your extension could be validated.<br>
<br>
If this were to work, you ought to be able to declare instance metadata of=
type ExtendedDublinCoreType (in namespace "edc"), and have it be=
successfully validated in schemas expecting straight up DublinCore. =
The details of actually getting this to work, I leave to you, but this=
seems to be their intent from a read through the XML-Schema=
documentation :)<br>
<br>
The impact on harvesters of instance metadata exported using types derived=
by extension is not yet clear to me...<br>
<br>
- Mick<br>
<br>
At 07:15 AM 1/31/01 -0500, you wrote:<br>
<blockquote type=3Dcite cite>Jeff, I think you've got the wrong approach=
here. Having spent the last<br>
hour or so staring at the xml schema primer at<br>
<a href=3D"http://www.w3.org/TR/xmlschema-0"=
eudora=3D"autourl">http://www.w3.org/TR/xmlschema-0</a> I found the=
explanation on importing<br>
types at <a href=3D"http://www.w3.org/TR/xmlschema-0/#import"=
eudora=3D"autourl">http://www.w3.org/TR/xmlschema-0/#import</a>. Using this=
mechanism<br>
you can pull in types (elements) from another namespace. E.g., you<br>
could define a schema carlmeta.xsd with a target namespace<br>
<a href=3D"http://foo.org/carlmeta"=
eudora=3D"autourl">http://foo.org/carlmeta</a> with an import of<br>
<a href=3D"http://purl.org/dc/elements/1.1"=
eudora=3D"autourl">http://purl.org/dc/elements/1.1</a>. I quote the=
primer:<br>
<br>
When schema components are imported from multiple namespaces, each<br>
namespace must be identified with a separate import element. The import<br>
elements themselves must appear as the first children of the schema<br>
element. Furthermore, each namespace must be associated with a prefix,<br>
using a standard namespace declaration, and that prefix is used to<br>
qualify references to any schema components belonging to that namespace.<br>
Finally, import elements optionally contain a schemaLocation attribute<br>
to help locate resources associated with the namespaces. <br>
<br>
Don't have time now to experiment with this but coming up with an<br>
example shouldn't be too hard.<br>
<br>
Carl<br>
<br>
> -----Original Message-----<br>
> From: Young,Jeff [<a href=3D"mailto:jyoung@oclc.org"=
eudora=3D"autourl">mailto:jyoung@oclc.org</a>]<br>
> Sent: Tuesday, January 30, 2001 4:58 PM<br>
> To: 'lagoze@cs.cornell.edu'<br>
> Subject: FW: [OAI-implementers] ListMetadataFormats problem<br>
> <br>
> <br>
> Hi Carl,<br>
> <br>
> I don't think things are as simple as I'd hoped. I want to <br>
> check with you<br>
> first, though, before I stir up more confusion in the <br>
> listserv. Apparently,<br>
> the xsi:schemaLocation element expects namespaces to be <br>
> paired with schema<br>
> locations. If this is true, then a single schema won't work for the<br>
> application I described below. Is there any reason that <br>
> schemas can't be<br>
> repeatable as well as namespaces in relation to metadata formats?<br>
> <br>
> Jeff<br>
> <br>
> > -----Original Message-----<br>
> > From: Young,Jeff [<a href=3D"mailto:jyoung@oclc.org"=
eudora=3D"autourl">mailto:jyoung@oclc.org</a>] <br>
> > Sent: Tuesday, January 30, 2001 4:01 PM<br>
> > To: 'OAI-implementers'<br>
> > Subject: [OAI-implementers] ListMetadataFormats problem<br>
> > <br>
> > <br>
> > I'm working on an OAI repository for a group that wants to <br>
> > define it's own<br>
> > metadata format. The trick is, this format will be a <br>
> > combination of Dublin<br>
> > Core elements and some new elements yet to be defined. The <br>
> > examples in the<br>
> > OAI specs, however, all assume that the metadata will consist <br>
> > of elements<br>
> > from a single namespace. I believe, for the most part, that <br>
> > the OAI spec<br>
> > doesn't preclude the use of multiple namespaces. For example, <br>
> > I imagine that<br>
> > the following XML fragment is likely to be acceptable:<br>
> > <br>
> > <combined=
xmlns:dc=3D"http://purl.org/dc/elements/1.1/"<br>
> > <x-tab> </x-tab>xmlns:myelems=3D"<a=
href=3D"http://www.myelems.com/"=
eudora=3D"autourl">http://www.myelems.com/</a>"<br>
> >=
<x-tab> </x-tab>xmlns:xsi=3D"..."<br>
> > <x-tab> </x-tab>xsi:schemaLocation=3D"=
<a=
href=3D"http://purl.org/dc/elements/1.1/%3E%20%3E%20http://www.myelems.com/=
%3E%20%3E%20http://www.myelems.com/combined.xsd"=
eudora=3D"autourl">http://purl.org/dc/elements/1.1/<br>
> >=
<x-tab> </x-tab><x-tab>  =
; </x-tab>http://www.myelems.com/<br>
> >=
<x-tab> </x-tab><x-tab>  =
; </x-tab>http://www.myelems.com/combined.xsd</a>">=
<br>
> > <dc:title>This is the title</dc:title><br>
> > =
<myelems:shoesize>12</myelems:shoesize><br>
> > </combined><br>
> > <br>
> > (As far as I can tell, specifying multiple namespaces in the<br>
> > xsi:schemaLocation attribute is perfectly valid.)<br>
> > <br>
> > Assuming no one sees any problems with this, I do think I see <br>
> > a problem with<br>
> > ListMetadataFormats.xsd. Now that multiple namespaces are <br>
> > involved, I expect<br>
> > that ListMetadataFormats will need to accommodate them with=
multiple<br>
> > metadataNamespace elements. The XML schema for <br>
> > ListMetadataFormats, however,<br>
> > sets the maxOccurs for metadataNamespace to one. I suspect <br>
> > this is easily<br>
> > changed to unbounded.<br>
> > <br>
> > Hopefully, the problem is no more involved than this, but <br>
> > someone may want<br>
> > to check my assumptions.<br>
> > <br>
> > Thanks,<br>
> > Jeff<br>
> > <br>
> > ---<br>
> > Jeffrey A. Young<br>
> > Senior Consulting Systems Analyst<br>
> > Office of Research, Mail Code 710<br>
> > OCLC Online Computer Library Center, Inc.<br>
> > 6565 Frantz Road<br>
> > Dublin, OH 43017-3395<br>
> > <a href=3D"http://www.oclc.org/"=
eudora=3D"autourl">www.oclc.org</a><br>
> > <br>
> >=
Voice:<x-tab> </x-tab>614-764-4342<br>
> >=
Fax:<x-tab> </x-tab><x-tab>&=
nbsp; </x-tab>614-764-2344<br>
> >=
Email:<x-tab> </x-tab>jyoung@oclc.org<br=
>
> > <br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > OAI-implementers mailing list<br>
> > OAI-implementers@oaisrv.nsdl.cornell.edu<br>
> > <a=
href=3D"http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers"=
eudora=3D"autourl">http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-impl=
ementers</a><br>
> > <br>
> <br>
_______________________________________________<br>
OAI-implementers mailing list<br>
OAI-implementers@oaisrv.nsdl.cornell.edu<br>
<a href=3D"http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers"=
eudora=3D"autourl">http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-impl=
ementers</a> </blockquote><br>
<div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D</div>
<div>Mick Bass, Sloan MOT 2000</div>
<div>R&D Project Manager</div>
<div>Hewlett-Packard Company</div>
<div>Cambridge, MA</div>
<br>
<div>617.253.6617 office</div>
<div>617.899.3938 mobile</div>
<div>617.452.3000 fax</div>
<div>617.627.9694 residence</div>
<br>
<div>bass@alum.mit.edu</div>
<div>mick_bass@hp.com</div>
<div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D</div>
</html>
--=====================_149350594==_.ALT--