LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  May 2013

BIBFRAME May 2013

Subject:

Re: BIBFRAME Digest - 4 May 2013 to 5 May 2013 (#2013-68)

From:

Carol Bream <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Mon, 6 May 2013 14:13:37 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (4799 lines)

I believe that BIBFRAME should seriously consider the concerns expressed by W3C. 
W3C is working in a number of closely related areas to expose and link metadata more seamlessly and with better interoperability.

For example:
http://www.w3.org/ns/adms
 
http://www.w3.org/TR/vocab-dcat/

There are some excellent clear tutorials on Linked data from the UK Open University site.  
Eg EUCLID Module 3
http://stadium.open.ac.uk/stadia/preview.php?whichevent=2177&s=29&option=&record=0&schedule=2805
_____________________________________________
Carol Bream 
Thesaurus and Réseaubib Service Manager
Central Library
European Commission
B-1049 Brussels
 
* +32-2-295.29 80 (direct phone) 
* +32-2-299.98.17 (fax)
http://ec.europa.eu/libraries/doc/index_en.htm


---------------------------------------------------------------------------------------------------------------------------------
The personal data contained in this document are dealt with in compliance with Regulation (EC) No 45/2001 of the European Parliament and of the Council of 18 December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data. For more information, see http://europa.eu/geninfo/legal_notices_en.htm#personaldata
Les données personnelles figurant dans ce document sont traitées dans le respect du Règlement (CE) 45/2001 du Parlement européen et du Conseil du 18 décembre 2000 relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel par les institutions et organes communautaires et à la libre circulation de ces données. Pour plus d'information, veuillez consulter http://europa.eu/geninfo/legal_notices_fr.htm#personaldata
-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of BIBFRAME automatic digest system
Sent: Monday, May 06, 2013 6:00 AM
To: [log in to unmask]
Subject: BIBFRAME Digest - 4 May 2013 to 5 May 2013 (#2013-68)

There are 13 messages totalling 5094 lines in this issue.

Topics of the day:

  1. Documents and improvements (5)
  2. Annotations (Was: Documents and improvements) (8)

----------------------------------------------------------------------

Date:    Sun, 5 May 2013 08:18:04 +0000
From:    Shlomo Sanders <[log in to unmask]>
Subject: Re: Documents and improvements

>
> ** **
>
> *From:* Bibliographic Framework Transition Initiative Forum [mailto:
> [log in to unmask]] *On Behalf Of *Young,Jeff (OR)
> *Sent:* Saturday, May 04, 2013 06:27
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Documents and improvements****
>
> ** **
>
> As Karen Coyle suggested (if I skimmed her recent comments correctly),
> what if you guys can't agree because you're both merely reinventing RDF
> graphs?****
>
> ** **
>
> Jeff
>
> Sent from my iPad****
>
>
> On May 3, 2013, at 4:16 PM, "Robert Sanderson" <[log in to unmask]>
> wrote:****
>
>   ** **
>
> Dear Sally, Ray and all,
>
> As co-chairs and co-editors of the W3C Open Annotation Community Group,
> Paolo, Herbert and I would again like to invite members of the BIBFRAME
> group to continue the discussion of interoperable annotation on the mailing
> list for the W3C Community Group. There is neither a cost nor membership
> requirement to joining.
>
> We feel it is fair to say that the Open Annotation effort has gained
> significant momentum, being the 6th largest community group with many
> active and ongoing discussions. However there is always room for
> improvement, and we still believe that both BIBFRAME and Open Annotation
> would benefit from an open discussion of the issues that resulted in the
> divergence which is clear in the annotation document.
>
> It is regrettable that the BIBFRAME annotation model is neither compatible
> nor interoperable with the Open Annotation Data Model, especially given the
> significant overlap between the target communities of Open Annotation and
> BIBFRAME.  We are disappointed that prior efforts to engage with the
> BIBFRAME community regarding annotation did not yield more constructive
> results to this stage. We hope that our invitation to discuss issues on the
> W3C Community Group will be met positively as we feel we owe it to our
> communities to work towards convergence.
>
> Respectfully,
>
> Robert Sanderson, Paolo Ciccarese, and Herbert Van de Sompel
>
>
>
> On Fri, May 3, 2013 at 12:08 AM, McCallum, Sally <[log in to unmask]> wrote:
> >
> > Thanks to all for your comments and ideas over the last few months.  The
> small team that we have called the Early Experimenters has prepared some
> discussion papers on difficult topics related to the BIBFRAME model and the
> developing draft vocabulary.  Now we want to put these papers on
> bibframe.org and begin discussion on this listserv.   By preparing
> background and recommendation papers we hope to help focus the discussion
> on the issues.
> >
> >
> >
> > The issues are some of the hard ones that all of us who deal with
> bibliographic data run into  -- always.   We are starting with the BIBFRAME
> Annotations paper, which you can find here:
> >
> >                 http://bibframe.org/documentation/annotations
> >
> > Then we hope to get discussion papers on BIBFRAME Authorities,
> Relationships, Schema.org, and Resource types out soon, followed by
> Holdings, Aggregates, and other issues.   These were prepared by various
> subgroups of the Experimenter team.  We do not want to send everything at
> once as we would like you to have focus rather than overload.
> >
> >
> >
> > We ask that when discussing the topics, you name your listserv comment
> with the topic short title (indicated on the topic paper) with an extra
> title to bind threads, e.g., "annotations--main point".
> >
> >
> >
> > We at LC continue to work on the conversion of MARC data, which, along
> with RDA, is the current feeder of the current vocabulary available at
> http://bibframe.org/.  In the last couple of months, we have made the
> following enhancements to the BIBFRAME website:
> >
> >
> >
> > -  Regularly updated to the vocabulary: http://bibframe.org/vocab/
> >
> > -  Added BIBFRAME example snippets in vocabulary section: e.g.
> http://bibframe.org/vocab/class-lcc
> >
> > -  Improved the MARC-to-BIBFRAME code: http://bibframe.org/tools/
> >
> > -  Added a set of Frequently Asked Questions: http://bibframe.org/faq/
> >
> >
> >
> > We have made every effort to update the MARC-to-BIBFRAME transformation
> code after modifying the vocabulary, and we plan to change and enhance the
> code based on feedback from the papers.  You can begin using the
> transformation code today as a reference and starting point for your own
> explorations.  See the contribute page to learn more:
> http://bibframe.org/contribute/.
> >
> >
> >
> > Please read the papers that we are be putting up on bibframe.org and
> participate in the discussion -- we are all in this together!
> >
> >
> >
> > Sally
> >
> >
> >
> > **************************
> >
> > Sally H. McCallum
> >
> > Chief, Network Development and Standards Office
> >
> > Library of Congress,  101 Independence Ave., SE
> >
> > Washington, DC 20540  USA
> >
> > [log in to unmask]
> >
> > Tel. 1-202-707-5119 -- Fax 1-202-707-0115
> >
> > **************************
> >
> >  ****
>
>

--f46d043893cd2b49a704dbf4ae2a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div style>Shlomo,</div><div style><br></div><div styl=
e>You weren&#39;t satisfied with the explanation given as to why this is no=
t the case?</div><div style><br></div><div style>Rob</div></div><div class=
=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Sun, May 5, 2013 at 10:18 AM, Shlomo =
Sanders <span dir=3D"ltr">&lt;<a href=3D"mailto:Shlomo.Sanders@exlibrisgrou=
p.com" target=3D"_blank">[log in to unmask]</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hear, hear<u></u><u></u><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Thanks,<u></u><u></u></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Shlomo<u></u><u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Experience the all-new, s=
inging and dancing interactive
<a href=3D"http://www.exlibrispublications.com/primo/" target=3D"_blank">Pr=
imo brochure</a> <u></u><u></u></span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Bibliogr=
aphic Framework Transition Initiative Forum [mailto:<a href=3D"mailto:BIBFR=
[log in to unmask]" target=3D"_blank">[log in to unmask]</a>]
<b>On Behalf Of </b>Young,Jeff (OR)<br>
<b>Sent:</b> Saturday, May 04, 2013 06:27<br>
<b>To:</b> <a href=3D"mailto:[log in to unmask]" target=3D"_blank">B=
[log in to unmask]</a><br>
<b>Subject:</b> Re: [BIBFRAME] Documents and improvements<u></u><u></u></sp=
an></p>
</div>
</div><div><div class=3D"h5">
<p class=3D"MsoNormal"><u></u>=A0<u></u></p>
<div>
<p class=3D"MsoNormal">As Karen Coyle suggested (if I skimmed her recent co=
mments correctly), what if you guys can&#39;t agree because you&#39;re both=
 merely reinventing RDF graphs?<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Jeff<br>
<br>
Sent from my iPad<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
On May 3, 2013, at 4:16 PM, &quot;Robert Sanderson&quot; &lt;<a href=3D"mai=
lto:[log in to unmask]" target=3D"_blank">[log in to unmask]</a>&gt; wrot=
e:<u></u><u></u></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class=3D"MsoNormal"><u></u>=A0<u></u></p>
</div>
<p class=3D"MsoNormal">Dear Sally, Ray and all,<br>
<br>
As co-chairs and co-editors of the W3C Open Annotation Community Group, Pao=
lo, Herbert and I would again like to invite members of the BIBFRAME group =
to continue the discussion of interoperable annotation on the mailing list =
for the W3C Community Group. There
 is neither a cost nor membership requirement to joining.<br>
<br>
We feel it is fair to say that the Open Annotation effort has gained signif=
icant momentum, being the 6th largest community group with many active and =
ongoing discussions. However there is always room for improvement, and we s=
till believe that both BIBFRAME
 and Open Annotation would benefit from an open discussion of the issues th=
at resulted in the divergence which is clear in the annotation document.<br=
>
<br>
It is regrettable that the BIBFRAME annotation model is neither compatible =
nor interoperable with the Open Annotation Data Model, especially given the=
 significant overlap between the target communities of Open Annotation and =
BIBFRAME. =A0We are disappointed that
 prior efforts to engage with the BIBFRAME community regarding annotation d=
id not yield more constructive results to this stage. We hope that our invi=
tation to discuss issues on the W3C Community Group will be met positively =
as we feel we owe it to our communities
 to work towards convergence.<br>
<br>
Respectfully,<br>
<br>
Robert Sanderson, Paolo Ciccarese, and Herbert Van de Sompel<br>
<br>
<br>
<br>
On Fri, May 3, 2013 at 12:08 AM, McCallum, Sally &lt;<a href=3D"mailto:smcc=
@loc.gov" target=3D"_blank">[log in to unmask]</a>&gt; wrote:<br>
&gt;<br>
&gt; Thanks to all for your comments and ideas over the last few months. =
=A0The small team that we have called the Early Experimenters has prepared =
some discussion papers on difficult topics related to the BIBFRAME model an=
d the developing draft vocabulary. =A0Now
 we want to put these papers on <a href=3D"http://bibframe.org" target=3D"_=
blank">bibframe.org</a> and begin discussion on this listserv. =A0 By prepa=
ring background and recommendation papers we hope to help focus the discuss=
ion on the issues.
<br>
&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; The issues are some of the hard ones that all of us who deal with bibl=
iographic data run into =A0-- always. =A0 We are starting with the BIBFRAME=
 Annotations paper, which you can find here:<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <a href=3D"http://bibframe.org/documen=
tation/annotations" target=3D"_blank">
http://bibframe.org/documentation/annotations</a><br>
&gt;<br>
&gt; Then we hope to get discussion papers on BIBFRAME Authorities, Relatio=
nships, <a href=3D"http://Schema.org" target=3D"_blank">
Schema.org</a>, and Resource types out soon, followed by Holdings, Aggregat=
es, and other issues. =A0 These were prepared by various subgroups of the E=
xperimenter team. =A0We do not want to send everything at once as we would =
like you to have focus rather than overload.<br>

&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; We ask that when discussing the topics, you name your listserv comment=
 with the topic short title (indicated on the topic paper) with an extra ti=
tle to bind threads, e.g., &quot;annotations--main point&quot;.<br>
&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; We at LC continue to work on the conversion of MARC data, which, along=
 with RDA, is the current feeder of the current vocabulary available at
<a href=3D"http://bibframe.org/" target=3D"_blank">http://bibframe.org/</a>=
. =A0In the last couple of months, we have made the following enhancements =
to the BIBFRAME website:<br>
&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; - =A0Regularly updated to the vocabulary: <a href=3D"http://bibframe.o=
rg/vocab/" target=3D"_blank">
http://bibframe.org/vocab/</a><br>
&gt;<br>
&gt; - =A0Added BIBFRAME example snippets in vocabulary section: e.g. <a hr=
ef=3D"http://bibframe.org/vocab/class-lcc" target=3D"_blank">
http://bibframe.org/vocab/class-lcc</a><br>
&gt;<br>
&gt; - =A0Improved the MARC-to-BIBFRAME code: <a href=3D"http://bibframe.or=
g/tools/" target=3D"_blank">
http://bibframe.org/tools/</a><br>
&gt;<br>
&gt; - =A0Added a set of Frequently Asked Questions: <a href=3D"http://bibf=
rame.org/faq/" target=3D"_blank">
http://bibframe.org/faq/</a><br>
&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; We have made every effort to update the MARC-to-BIBFRAME transformatio=
n code after modifying the vocabulary, and we plan to change and enhance th=
e code based on feedback from the papers. =A0You can begin using the transf=
ormation code today as a reference and
 starting point for your own explorations. =A0See the contribute page to le=
arn more:
<a href=3D"http://bibframe.org/contribute/" target=3D"_blank">http://bibfra=
me.org/contribute/</a>.<br>
&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; Please read the papers that we are be putting up on <a href=3D"http://=
bibframe.org" target=3D"_blank">
bibframe.org</a> and participate in the discussion -- we are all in this to=
gether!<br>
&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; Sally<br>
&gt;<br>
&gt; =A0<br>
&gt;<br>
&gt; **************************<br>
&gt;<br>
&gt; Sally H. McCallum<br>
&gt;<br>
&gt; Chief, Network Development and Standards Office<br>
&gt;<br>
&gt; Library of Congress, =A0101 Independence Ave., SE<br>
&gt;<br>
&gt; Washington, DC 20540 =A0USA<br>
&gt;<br>
&gt; <a href=3D"mailto:[log in to unmask]" target=3D"_blank">[log in to unmask]</a><br>
&gt;<br>
&gt; Tel. <a href=3D"tel:1-202-707-5119" target=3D"_blank">1-202-707-5119</=
a> -- Fax <a href=3D"tel:1-202-707-0115" target=3D"_blank">
1-202-707-0115</a><br>
&gt;<br>
&gt; **************************<br>
&gt;<br>
&gt; =A0<u></u><u></u></p>
</div>
</div>
</blockquote>
</div></div></div>
</div>

</blockquote></div><br></div>

--f46d043893cd2b49a704dbf4ae2a--

------------------------------

Date:    Sun, 5 May 2013 11:17:28 +0200
From:    Robert Sanderson <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

--001a11c353a29bc0c404dbf50d06
Content-Type: text/plain; charset=ISO-8859-1

Hi Karen,

On Sat, May 4, 2013 at 6:15 PM, Karen Coyle <[log in to unmask]> wrote:

>  Robert, thank you for your answer. To begin with, I don't speak for
> BIBFRAME, not being in any way part of that development, but I would like
> to reply to some points from a library point of view. What I suspect that
> we have here are two things called "annotation" that are considerably
> different in their usage. This does not mean that they could not be brought
> together, but we should look beyond the term itself to the use cases.
>

I completely agree.


>  * A highlighted span of text.
> * An annotation that refers to multiple segments of a resource, multiple
> resources or multiple segments of multiple resources.
> * Where there are, equivalently, multiple comments...
>
> Of the above, the only one that I perceive as a library cataloging data
> use case is the multi-lingual one.
>

Agreed, however these were simply to demonstrate that annotations expressed
in RDF require more than a single reified triple, to refute the claim that
we're simply reinventing RDF graphs.  There needs to be an ontology and
defined structure.


> I also note that one of the annotation types in OA is parallel to the
> library use case of subject assignment. What I see here is a difference
> between the annotation of documents, something similar to "citing" or
> "commenting on," and the addition of information to a set of descriptive
> metadata. It is for this reason that I propose that we look closer at the
> use cases and determine if we aren't making too much of the use of the term
> "annotation."
>

Yes, definitely.  The cataloguing type of use cases I would see as clearly
annotations:

* Reviews / Notes
* Tagging / Subject classification
* Citations

Essentially, when the information is provided by a third party, then it
would be good to be expressed as an Annotation such that the provenance
information is maintained and is compatible with other systems that use
Open Annotation.

The expression of arbitrary metadata could be expressed as annotations, but
I would like to be convinced why the additional structure is required,
compared to simply adding the information directly.  This is one of the
issues with the "inline annotation" -- it simply makes no sense either in
RDF terms (where the concept of a record doesn't exist) or for the use of
annotations, which are intended to be an overlay distinct from the
annotated resource.

Unless you're claiming that annotation does not require a model or any new
> vocabulary/ontology? At the very least there needs to be a notion of
> provenance of the annotation graph, and the resources involved in it.
>
>
> AFAIK, provenance is on its way to becoming a generalized concept in RDF,
> therefore is not unique to OA. Provenance will be very important to
> libraries where the concept of "authoritativeness" of data is essential to
> our extensive sharing of metadata.
>

Indeed, W3C recently approved the recommendation status of the PROV work,
which we use.


And secondly to enumerate the areas of incompatiblity:
>
>  * bf:annotationBodyLiteral
> This pattern is not available in the Open Annotation model, after much
> discussion.
> The wiki discussion page:
> http://www.w3.org/community/openannotation/wiki/Textual_Bodies
> The distilled rationale in the specification:
> http://openannotation.org/spec/core/core.html#BodyEmbed
>
>  Note that in the bibframe document, the solution we adopt is also used,
> being the Content in RDF specification.
> Also note that this spec is less mature than the Open Annotation spec, yet
> the Annotation model is reproduced and the content in RDF model is reused.
>
> OA uses Dublin Core types vocabulary for this. That may be a solution, but
> only if one accepts the OA structure. What we in the library world need to
> think about, IMO, is how far we want to go with typing our annotations, and
> what the trade-off is in terms of complexity.
>

The point I was trying to make is that the bibframe annotation model has a
property bf:annotationBodyLiteral, which has a literal as the object.  The
Open Annotation model explicitly does not allow this, for several important
and well discussed reasons.  Thus a point where the two models are not
compatible.

The use of DC Types in OA is to express the type of the resource in order
for clients to know how, in general, to process it.  For example, knowing
that a resource is an image would allow a browser based client to use the
<img> tag, even if it doesn't recognize the media type or it isn't
provided.


Note that there is nothing about library data that would prevent anyone
> from applying an Open Annotation to the data. The question is, do we want
> this to be the only way to, for example, assign a subject heading to a
> Work? Or to link reviews to a bibliographic description? Library data has a
> different mechanism for linking subject headings to Works, called
> "Authorities." This was my point in the earlier email [1] about separating
> the basic elements of cataloging (resulting in bibliographic metadata) from
> user-supplied "annotations." If the latter, then OA could be the standard
> for user-supplied annotations, while library data would continue to use its
> duality of "description and access."
>

Yes, completely agree.  As any metadata could in theory be supplied by a
third party, it seems like everything would end up an annotation following
that route.


What you may not know is that the concept of "annotation" is far from
> accepted in library cataloging. It was introduced with BIBFRAME and my
> guess is that the vast majority of librarians do not have this concept in
> their mental tool-kit. My impression is that BIBFRAME is so far from
> "cooked" that what we see today in the documentation may not be what is at
> the end. All the more reason to have this conversation about annotations
> now while BIBFRAME is still somewhat fluid. I can tell you that once a
> standard gets accepted and implemented in the library world, changes become
> extremely costly, which is why we are struggling today with a 40-year-old
> data standard that no longer meets our needs.
>

Yes, my background is libraries and archives ... I've spent a long time
with MARC records and Z39.50. I was also one of the original editors for
SRU before it moved to OASIS, for example.

 * Motivation vs SubClassing
>
>  The Open Annotation model recommends motivations as a means of
> expressing the rationale behind the creation of the Annotation, yet the
> Bibframe model uses subclasses of Annotation.
>  The motivation system is extensible and able to be integrated post-factum
> across communities as it is based on the SKOS model, rather than simple
> subclassing.
>
>  See:
> http://openannotation.org/spec/core/core.html#Motivations
>  http://openannotation.org/spec/core/appendices.html#ExtendingMotivations
>
>
> If we see BIBFRAME annotations being assigned by catalogers, then
> "motivation" isn't a terribly relevant concept. Cataloging follows
> cataloging rules and isn't "motivated" individually. However, I can see a
> need to type the annotations, and that could be through a property
> sub-type, an annotation sub-class, or using a mechanism like OA motivations
> (although not actually OA Motivations). Again, it seems worth thinking
> about the variety of annotations that libraries may use, and the best way
> to manage and extend that.
>

Yes, the motivation is really just editing their own records ... which is
what they should be doing directly, rather than annotating, in my (and I
think your!) opinion.

Motivations in OA replace subclassing for things like "Comment" or "Review"
to allow cross-community alignment using the SKOS model. Some communities,
such as this one, may see Review very differently to others (such as peer
review or online product reviews or movie reviews) and subclassing often
isn't sufficient or feasible.

  * Inline Annotations
> These annotations do not have an explicit target, which is required in
> Open Annotation.  It could be argued that bf:annotation is the inverse
> property of oa:hasTarget, but that is not clear from the current document.
> Also, in RDF there is no notion of "embedded" or "records", there is a
> single global graph that uses the open world assumption.  This "inline"
> annotation is typical closed world thinking, where a "record" is something
> that exists.  So to say "the Target is assumed to be the resource in which
> it is embedded" is not meaningful.
>
>
> I wouldn't assume that the BIBFRAME data will exist *as is* in the open
> world.
>

Then I would seriously question why RDF is being used at all.



> It may (I hope) be more easily translatable to the open world, but
> libraries need a sharable data format that replaces the current record
> format. So I do think that it is appropriate to *also* think of BIBFRAME as
> a record, and that some of its "record-ness" may remain within a library
> silo because it is only relevant there. A primary use case for library
> metadata is the sharing of descriptions of published materials that make up
> the inventories of library holdings, and are key to the management
> functions of library systems (acquisitions, collection development,
> circulation). These descriptions are indeed "records" regardless of the
> technology being used to hold the metadata. The soon-to-be-current
> cataloging rules separate "description" and "access." To my mind, the
> "access" part is most interesting as linked data, while the "description"
> part functions as a bound package (c.f. ISBD as the data "core").
>

We seem to be in violent agreement :)

* The Reinvention of the Model
> There's no reason to reinvent all of the terms, classes, properties and
> relationships. The redundancy is astounding, and unnecessary. Especially,
> as above, given the re-use of DC Terms and Content in RDF.  One would
> expect, given the negative view from the "Reuse of Ontologies" thread on
> this mailing list, that these would also be recreated in the bf ontology.
>
> As I say above, until we study the library use cases, what we have here
> may just be a coincidence of terminology. I believe that is the first step:
> compare use cases.
>

Yes.

Was the choice of annotation as a model discussed on this list (and hence
available in the archives) or was it simply presented fait accompli?

Rob

--001a11c353a29bc0c404dbf50d06
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div style>Hi Karen,</div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Sat, May 4, 2013 at 6:15 PM, Karen Coyle <=
span dir=3D"ltr">&lt;<a href=3D"mailto:[log in to unmask]" target=3D"_blank">=
[log in to unmask]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Robert, thank you for your answer. To begin with, I don&#39;t speak for
    BIBFRAME, not being in any way part of that development, but I would
    like to reply to some points from a library point of view. What I
    suspect that we have here are two things called &quot;annotation&quot; =
that
    are considerably different in their usage. This does not mean that
    they could not be brought together, but we should look beyond the
    term itself to the use cases. <br></div></blockquote><div><br></div><di=
v style>I completely agree. =A0</div><div style><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im"><blockquote typ=
e=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div style=3D"font-f=
amily:arial,sans-serif;font-size:13px"><br>
          </div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">* A
            highlighted span of text.=A0</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">* An
            annotation that refers to multiple segments of a resource,
            multiple resources or multiple segments of multiple
            resources.=A0</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">*
            Where there are, equivalently, multiple comments...</div></div>=
</div></blockquote></div></div></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im"><span style=3D"=
color:rgb(34,34,34)">Of the above, the only one that I perceive as a librar=
y cataloging
    data use case is the multi-lingual one.</span></div></div></blockquote>=
<div><br></div><div style>Agreed, however these were simply to demonstrate =
that annotations expressed in RDF require more than a single reified triple=
, to refute the claim that we&#39;re simply reinventing RDF graphs. =A0Ther=
e needs to be an ontology and defined structure.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><d=
iv class=3D"im">
<span style=3D"color:rgb(34,34,34)"> I also note that one of the
    annotation types in OA is parallel to the library use case of
    subject assignment. What I see here is a difference between the
    annotation of documents, something similar to &quot;citing&quot; or
    &quot;commenting on,&quot; and the addition of information to a set of
    descriptive metadata. It is for this reason that I propose that we
    look closer at the use cases and determine if we aren&#39;t making too
    much of the use of the term &quot;annotation.&quot;=A0</span></div></di=
v></blockquote><div><br></div><div><div>Yes, definitely. =A0The cataloguing=
 type of use cases I would see as clearly annotations:</div><div><br></div>
<div>* Reviews / Notes</div><div>* Tagging / Subject classification<br></di=
v><div>* Citations</div></div><div><br></div><div style>Essentially, when t=
he information is provided by a third party, then it would be good to be ex=
pressed as an Annotation such that the provenance information is maintained=
 and is compatible with other systems that use Open Annotation.</div>
<div><br></div><div style>The expression of arbitrary metadata could be exp=
ressed as annotations, but I would like to be convinced why the additional =
structure is required, compared to simply adding the information directly. =
=A0This is one of the issues with the &quot;inline annotation&quot; -- it s=
imply makes no sense either in RDF terms (where the concept of a record doe=
sn&#39;t exist) or for the use of annotations, which are intended to be an =
overlay distinct from the annotated resource.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><=
div class=3D"im">
<blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
style=3D"font-family:arial,sans-serif;font-size:13px">Unless
            you&#39;re claiming that annotation does not require a model or
            any new vocabulary/ontology? At the very least there needs
            to be a notion of provenance of the annotation graph, and
            the resources involved in it.<br></div>
        </div>
      </div>
    </blockquote>
    <br></div>
    AFAIK, provenance is on its way to becoming a generalized concept in
    RDF, therefore is not unique to OA. Provenance will be very
    important to libraries where the concept of &quot;authoritativeness&quo=
t; of
    data is essential to our extensive sharing of metadata.</div></blockquo=
te><div><br></div><div style>Indeed, W3C recently approved the recommendati=
on status of the PROV work, which we use.</div><div style><br></div><div st=
yle>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><div c=
lass=3D"im">
<span style=3D"font-family:arial,sans-serif;font-size:13px">And
            secondly to enumerate the areas of incompatiblity:</span><br><b=
lockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra">
         =20
          <div style=3D"font-family:arial,sans-serif;font-size:13px">
            * bf:annotationBodyLiteral</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">This
            pattern is not available in the Open Annotation model, after
            much discussion. =A0</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">The
            wiki discussion page:=A0<a href=3D"http://www.w3.org/community/=
openannotation/wiki/Textual_Bodies" target=3D"_blank">http://www.w3.org/com=
munity/openannotation/wiki/Textual_Bodies</a></div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">The
            distilled rationale in the specification:=A0<a href=3D"http://o=
penannotation.org/spec/core/core.html#BodyEmbed" target=3D"_blank">http://o=
penannotation.org/spec/core/core.html#BodyEmbed</a></div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px"><br>
          </div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">Note
            that in the bibframe document, the solution we adopt is also
            used, being the Content in RDF specification.</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">Also
            note that this spec is less mature than the Open Annotation
            spec, yet the Annotation model is reproduced and the content
            in RDF model is reused.</div>
        </div>
      </div>
    </blockquote></div>
    OA uses Dublin Core types vocabulary for this. That may be a
    solution, but only if one accepts the OA structure. What we in the
    library world need to think about, IMO, is how far we want to go
    with typing our annotations, and what the trade-off is in terms of
    complexity.</div></blockquote><div><br></div><div style>The point I was=
 trying to make is that the bibframe annotation model has a property bf:ann=
otationBodyLiteral, which has a literal as the object. =A0The Open Annotati=
on model explicitly does not allow this, for several important and well dis=
cussed reasons. =A0Thus a point where the two models are not compatible.</d=
iv>
<div style><br></div><div style>The use of DC Types in OA is to express the=
 type of the resource in order for clients to know how, in general, to proc=
ess it. =A0For example, knowing that a resource is an image would allow a b=
rowser based client to use the &lt;img&gt; tag, even if it doesn&#39;t reco=
gnize the media type or it isn&#39;t provided.=A0</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" tex=
t=3D"#000000">
Note that there is nothing about library data that would prevent
    anyone from applying an Open Annotation to the data. The question
    is, do we want this to be the only way to, for example, assign a
    subject heading to a Work? Or to link reviews to a bibliographic
    description? Library data has a different mechanism for linking
    subject headings to Works, called &quot;Authorities.&quot; This was my =
point
    in the earlier email [1] about separating the basic elements of
    cataloging (resulting in bibliographic metadata) from user-supplied
    &quot;annotations.&quot; If the latter, then OA could be the standard f=
or
    user-supplied annotations, while library data would continue to use
    its duality of &quot;description and access.&quot;<br></div></blockquot=
e><div><br></div><div style>Yes, completely agree. =A0As any metadata could=
 in theory be supplied by a third party, it seems like everything would end=
 up an annotation following that route. =A0</div>
<div style><br></div><div style><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor=3D"=
#FFFFFF" text=3D"#000000">
What you may not know is that the concept of &quot;annotation&quot; is far
    from accepted in library cataloging. It was introduced with BIBFRAME
    and my guess is that the vast majority of librarians do not have
    this concept in their mental tool-kit. My impression is that
    BIBFRAME is so far from &quot;cooked&quot; that what we see today in th=
e
    documentation may not be what is at the end. All the more reason to
    have this conversation about annotations now while BIBFRAME is still
    somewhat fluid. I can tell you that once a standard gets accepted
    and implemented in the library world, changes become extremely
    costly, which is why we are struggling today with a 40-year-old data
    standard that no longer meets our needs.</div></blockquote><div><br></d=
iv><div style>Yes, my background is libraries and archives ... I&#39;ve spe=
nt a long time with MARC records and Z39.50. I was also one of the original=
 editors for SRU before it moved to OASIS, for example.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><=
div class=3D"im">
<blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
         =20
          <div style=3D"font-family:arial,sans-serif;font-size:13px">*
            Motivation vs SubClassing</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px"><br>
          </div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">
            The Open Annotation model recommends motivations as a means
            of expressing the rationale behind the creation of the
            Annotation, yet the Bibframe model uses subclasses of
            Annotation.</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">
            The motivation system is extensible and able to be
            integrated post-factum across communities as it is based on
            the SKOS model, rather than simple subclassing.</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">
            <br>
          </div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">See:</=
div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px"><a hre=
f=3D"http://openannotation.org/spec/core/core.html#Motivations" target=3D"_=
blank">http://openannotation.org/spec/core/core.html#Motivations</a><br>
          </div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px"><a hre=
f=3D"http://openannotation.org/spec/core/appendices.html#ExtendingMotivatio=
ns" target=3D"_blank">http://openannotation.org/spec/core/appendices.html#E=
xtendingMotivations</a><br>

          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    If we see BIBFRAME annotations being assigned by catalogers, then
    &quot;motivation&quot; isn&#39;t a terribly relevant concept. Catalogin=
g follows
    cataloging rules and isn&#39;t &quot;motivated&quot; individually. Howe=
ver, I can
    see a need to type the annotations, and that could be through a
    property sub-type, an annotation sub-class, or using a mechanism
    like OA motivations (although not actually OA Motivations). Again,
    it seems worth thinking about the variety of annotations that
    libraries may use, and the best way to manage and extend that.</div></b=
lockquote><div><br></div><div style>Yes, the motivation is really just edit=
ing their own records ... which is what they should be doing directly, rath=
er than annotating, in my (and I think your!) opinion.</div>
<div><br></div><div style>Motivations in OA replace subclassing for things =
like &quot;Comment&quot; or &quot;Review&quot; to allow cross-community ali=
gnment using the SKOS model. Some communities, such as this one, may see Re=
view very differently to others (such as peer review or online product revi=
ews or movie reviews) and subclassing often isn&#39;t sufficient or feasibl=
e.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><=
div class=3D"im">
<blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div style=3D"font-family:arial,sans-serif;font-size:13px">
          </div>
         =20
          <div style=3D"font-family:arial,sans-serif;font-size:13px">*
            Inline Annotations</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">These
            annotations do not have an explicit target, which is
            required in Open Annotation. =A0It could be argued that
            bf:annotation is the inverse property of oa:hasTarget, but
            that is not clear from the current document.</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">Also,
            in RDF there is no notion of &quot;embedded&quot; or &quot;reco=
rds&quot;, there
            is a single global graph that uses the open world
            assumption. =A0This &quot;inline&quot; annotation is typical cl=
osed
            world thinking, where a &quot;record&quot; is something that ex=
ists.
            =A0So to say &quot;the Target is assumed to be the resource in
            which it is embedded&quot; is not meaningful.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    I wouldn&#39;t assume that the BIBFRAME data will exist *as is* in the
    open world. </div></blockquote><div><br></div><div style>Then I would s=
eriously question why RDF is being used at all.</div><div><br></div><div>=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">It may (I hope) be more easily tr=
anslatable to the open
    world, but libraries need a sharable data format that replaces the
    current record format. So I do think that it is appropriate to
    *also* think of BIBFRAME as a record, and that some of its
    &quot;record-ness&quot; may remain within a library silo because it is =
only
    relevant there. A primary use case for library metadata is the
    sharing of descriptions of published materials that make up the
    inventories of library holdings, and are key to the management
    functions of library systems (acquisitions, collection development,
    circulation). These descriptions are indeed &quot;records&quot; regardl=
ess of
    the technology being used to hold the metadata. The
    soon-to-be-current cataloging rules separate &quot;description&quot; an=
d
    &quot;access.&quot; To my mind, the &quot;access&quot; part is most int=
eresting as
    linked data, while the &quot;description&quot; part functions as a boun=
d
    package (c.f. ISBD as the data &quot;core&quot;). <br></div></blockquot=
e><div><br></div><div style>We seem to be in violent agreement :)=A0</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im"><blockquote typ=
e=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div style=3D"font-f=
amily:arial,sans-serif;font-size:13px">* The
            Reinvention of the Model</div>
          <div style=3D"font-family:arial,sans-serif;font-size:13px">There&=
#39;s
            no reason to reinvent all of the terms, classes, properties
            and relationships. The redundancy is astounding, and
            unnecessary. Especially, as above, given the re-use of DC
            Terms and Content in RDF. =A0One would expect, given the
            negative view from the &quot;Reuse of Ontologies&quot; thread o=
n this
            mailing list, that these would also be recreated in the bf
            ontology.</div>
        </div>
      </div>
    </blockquote></div>
    As I say above, until we study the library use cases, what we have
    here may just be a coincidence of terminology. I believe that is the
    first step: compare use cases.<br></div></blockquote><div><br></div><di=
v style>Yes.</div><div>=A0</div><div style>Was the choice of annotation as =
a model discussed on this list (and hence available in the archives) or was=
 it simply presented fait accompli?</div>
<div style><br></div><div style>Rob</div><div><br></div></div></div></div>

--001a11c353a29bc0c404dbf50d06--

------------------------------

Date:    Sun, 5 May 2013 10:11:19 +0000
From:    Shlomo Sanders <[log in to unmask]>
Subject: Re: Documents and improvements

--_000_768F135D8DFF3A4A9E4BFF0549723FD953C51B7CILEXM02CorpExli_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree with Jeff 100%.
Instead of consolidating more and more stuff are defined.
All for good reasons, but the bottom line will be longer for vendors to sup=
port, more bugs.....

Thanks,
Shlomo

Experience the all-new, singing and dancing interactive Primo brochure<http=
://www.exlibrispublications.com/primo/>

From: Bibliographic Framework Transition Initiative Forum [mailto:BIBFRAME@=
LISTSERV.LOC.GOV] On Behalf Of Robert Sanderson
Sent: Sunday, May 05, 2013 11:51
To: [log in to unmask]
Subject: Re: [BIBFRAME] Documents and improvements


Shlomo,

You weren't satisfied with the explanation given as to why this is not the =
case?

Rob

On Sun, May 5, 2013 at 10:18 AM, Shlomo Sanders <Shlomo.Sanders@exlibrisgro=
up.com<mailto:[log in to unmask]>> wrote:
Hear, hear

Thanks,
Shlomo

Experience the all-new, singing and dancing interactive Primo brochure<http=
://www.exlibrispublications.com/primo/>

From: Bibliographic Framework Transition Initiative Forum [mailto:BIBFRAME@=
LISTSERV.LOC.GOV<mailto:[log in to unmask]>] On Behalf Of Young,Jeff=
 (OR)
Sent: Saturday, May 04, 2013 06:27
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] Documents and improvements

As Karen Coyle suggested (if I skimmed her recent comments correctly), what=
 if you guys can't agree because you're both merely reinventing RDF graphs?

Jeff

Sent from my iPad

On May 3, 2013, at 4:16 PM, "Robert Sanderson" <[log in to unmask]<mailto:=
[log in to unmask]>> wrote:

Dear Sally, Ray and all,

As co-chairs and co-editors of the W3C Open Annotation Community Group, Pao=
lo, Herbert and I would again like to invite members of the BIBFRAME group =
to continue the discussion of interoperable annotation on the mailing list =
for the W3C Community Group. There is neither a cost nor membership require=
ment to joining.

We feel it is fair to say that the Open Annotation effort has gained signif=
icant momentum, being the 6th largest community group with many active and =
ongoing discussions. However there is always room for improvement, and we s=
till believe that both BIBFRAME and Open Annotation would benefit from an o=
pen discussion of the issues that resulted in the divergence which is clear=
 in the annotation document.

It is regrettable that the BIBFRAME annotation model is neither compatible =
nor interoperable with the Open Annotation Data Model, especially given the=
 significant overlap between the target communities of Open Annotation and =
BIBFRAME.  We are disappointed that prior efforts to engage with the BIBFRA=
ME community regarding annotation did not yield more constructive results t=
o this stage. We hope that our invitation to discuss issues on the W3C Comm=
unity Group will be met positively as we feel we owe it to our communities =
to work towards convergence.

Respectfully,

Robert Sanderson, Paolo Ciccarese, and Herbert Van de Sompel



On Fri, May 3, 2013 at 12:08 AM, McCallum, Sally <[log in to unmask]<mailto:smcc@=
loc.gov>> wrote:
>
> Thanks to all for your comments and ideas over the last few months.  The =
small team that we have called the Early Experimenters has prepared some di=
scussion papers on difficult topics related to the BIBFRAME model and the d=
eveloping draft vocabulary.  Now we want to put these papers on bibframe.or=
g<http://bibframe.org> and begin discussion on this listserv.   By preparin=
g background and recommendation papers we hope to help focus the discussion=
 on the issues.
>
>
>
> The issues are some of the hard ones that all of us who deal with bibliog=
raphic data run into  -- always.   We are starting with the BIBFRAME Annota=
tions paper, which you can find here:
>
>                 http://bibframe.org/documentation/annotations
>
> Then we hope to get discussion papers on BIBFRAME Authorities, Relationsh=
ips, Schema.org<http://Schema.org>, and Resource types out soon, followed b=
y Holdings, Aggregates, and other issues.   These were prepared by various =
subgroups of the Experimenter team.  We do not want to send everything at o=
nce as we would like you to have focus rather than overload.
>
>
>
> We ask that when discussing the topics, you name your listserv comment wi=
th the topic short title (indicated on the topic paper) with an extra title=
 to bind threads, e.g., "annotations--main point".
>
>
>
> We at LC continue to work on the conversion of MARC data, which, along wi=
th RDA, is the current feeder of the current vocabulary available at http:/=
/bibframe.org/.  In the last couple of months, we have made the following e=
nhancements to the BIBFRAME website:
>
>
>
> -  Regularly updated to the vocabulary: http://bibframe.org/vocab/
>
> -  Added BIBFRAME example snippets in vocabulary section: e.g. http://bib=
frame.org/vocab/class-lcc
>
> -  Improved the MARC-to-BIBFRAME code: http://bibframe.org/tools/
>
> -  Added a set of Frequently Asked Questions: http://bibframe.org/faq/
>
>
>
> We have made every effort to update the MARC-to-BIBFRAME transformation c=
ode after modifying the vocabulary, and we plan to change and enhance the c=
ode based on feedback from the papers.  You can begin using the transformat=
ion code today as a reference and starting point for your own explorations.=
  See the contribute page to learn more: http://bibframe.org/contribute/.
>
>
>
> Please read the papers that we are be putting up on bibframe.org<http://b=
ibframe.org> and participate in the discussion -- we are all in this togeth=
er!
>
>
>
> Sally
>
>
>
> **************************
>
> Sally H. McCallum
>
> Chief, Network Development and Standards Office
>
> Library of Congress,  101 Independence Ave., SE
>
> Washington, DC 20540  USA
>
> [log in to unmask]<mailto:[log in to unmask]>
>
> Tel. 1-202-707-5119<tel:1-202-707-5119> -- Fax 1-202-707-0115<tel:1-202-7=
07-0115>
>
> **************************
>
>


--_000_768F135D8DFF3A4A9E4BFF0549723FD953C51B7CILEXM02CorpExli_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree with Jeff 100%.<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Instead of consolidating =
more and more stuff are defined.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">All for good reasons, but=
 the bottom line will be longer for vendors to support, more bugs&#8230;..<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Shlomo<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Experience the all-new, s=
inging and dancing interactive
<a href=3D"http://www.exlibrispublications.com/primo/">Primo brochure</a> <=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Bibliogr=
aphic Framework Transition Initiative Forum [mailto:[log in to unmask]
OV]
<b>On Behalf Of </b>Robert Sanderson<br>
<b>Sent:</b> Sunday, May 05, 2013 11:51<br>
<b>To:</b> [log in to unmask]<br>
<b>Subject:</b> Re: [BIBFRAME] Documents and improvements<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">Shlomo,<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">You weren't satisfied with the explanation given as =
to why this is not the case?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Rob<o:p></o:p></p>
</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">On Sun, May 5, 2013 at 10:18 AM, Shlomo Sanders &lt;=
<a href=3D"mailto:[log in to unmask]" target=3D"_blank">Shlom=
[log in to unmask]</a>&gt; wrote:<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">Hear, hear</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">Thanks,</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">Shlomo</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">Experience the all-new, singing and dan=
cing interactive
<a href=3D"http://www.exlibrispublications.com/primo/" target=3D"_blank">Pr=
imo brochure</a>
</span><o:p></o:p></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=
&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=
t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Bibliographic Framewor=
k Transition
 Initiative Forum [mailto:<a href=3D"mailto:[log in to unmask]" targ=
et=3D"_blank">[log in to unmask]</a>]
<b>On Behalf Of </b>Young,Jeff (OR)<br>
<b>Sent:</b> Saturday, May 04, 2013 06:27<br>
<b>To:</b> <a href=3D"mailto:[log in to unmask]" target=3D"_blank">B=
[log in to unmask]</a><br>
<b>Subject:</b> Re: [BIBFRAME] Documents and improvements</span><o:p></o:p>=
</p>
</div>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">&nbsp;<o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">As Karen Coyle suggested (if I skimmed her recent comments correct=
ly), what if you guys can't agree because you're both merely reinventing RD=
F graphs?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">Jeff<br>
<br>
Sent from my iPad<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=
t"><br>
On May 3, 2013, at 4:16 PM, &quot;Robert Sanderson&quot; &lt;<a href=3D"mai=
lto:[log in to unmask]" target=3D"_blank">[log in to unmask]</a>&gt; wrot=
e:<o:p></o:p></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">&nbsp;<o:p></o:p></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">Dear Sally, Ray and all,<br>
<br>
As co-chairs and co-editors of the W3C Open Annotation Community Group, Pao=
lo, Herbert and I would again like to invite members of the BIBFRAME group =
to continue the discussion of interoperable annotation on the mailing list =
for the W3C Community Group. There
 is neither a cost nor membership requirement to joining.<br>
<br>
We feel it is fair to say that the Open Annotation effort has gained signif=
icant momentum, being the 6th largest community group with many active and =
ongoing discussions. However there is always room for improvement, and we s=
till believe that both BIBFRAME
 and Open Annotation would benefit from an open discussion of the issues th=
at resulted in the divergence which is clear in the annotation document.<br=
>
<br>
It is regrettable that the BIBFRAME annotation model is neither compatible =
nor interoperable with the Open Annotation Data Model, especially given the=
 significant overlap between the target communities of Open Annotation and =
BIBFRAME. &nbsp;We are disappointed that
 prior efforts to engage with the BIBFRAME community regarding annotation d=
id not yield more constructive results to this stage. We hope that our invi=
tation to discuss issues on the W3C Community Group will be met positively =
as we feel we owe it to our communities
 to work towards convergence.<br>
<br>
Respectfully,<br>
<br>
Robert Sanderson, Paolo Ciccarese, and Herbert Van de Sompel<br>
<br>
<br>
<br>
On Fri, May 3, 2013 at 12:08 AM, McCallum, Sally &lt;<a href=3D"mailto:smcc=
@loc.gov" target=3D"_blank">[log in to unmask]</a>&gt; wrote:<br>
&gt;<br>
&gt; Thanks to all for your comments and ideas over the last few months. &n=
bsp;The small team that we have called the Early Experimenters has prepared=
 some discussion papers on difficult topics related to the BIBFRAME model a=
nd the developing draft vocabulary. &nbsp;Now
 we want to put these papers on <a href=3D"http://bibframe.org" target=3D"_=
blank">bibframe.org</a> and begin discussion on this listserv. &nbsp; By pr=
eparing background and recommendation papers we hope to help focus the disc=
ussion on the issues.
<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; The issues are some of the hard ones that all of us who deal with bibl=
iographic data run into &nbsp;-- always. &nbsp; We are starting with the BI=
BFRAME Annotations paper, which you can find here:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <a href=3D"htt=
p://bibframe.org/documentation/annotations" target=3D"_blank">
http://bibframe.org/documentation/annotations</a><br>
&gt;<br>
&gt; Then we hope to get discussion papers on BIBFRAME Authorities, Relatio=
nships, <a href=3D"http://Schema.org" target=3D"_blank">
Schema.org</a>, and Resource types out soon, followed by Holdings, Aggregat=
es, and other issues. &nbsp; These were prepared by various subgroups of th=
e Experimenter team. &nbsp;We do not want to send everything at once as we =
would like you to have focus rather than overload.<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; We ask that when discussing the topics, you name your listserv comment=
 with the topic short title (indicated on the topic paper) with an extra ti=
tle to bind threads, e.g., &quot;annotations--main point&quot;.<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; We at LC continue to work on the conversion of MARC data, which, along=
 with RDA, is the current feeder of the current vocabulary available at
<a href=3D"http://bibframe.org/" target=3D"_blank">http://bibframe.org/</a>=
. &nbsp;In the last couple of months, we have made the following enhancemen=
ts to the BIBFRAME website:<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; - &nbsp;Regularly updated to the vocabulary: <a href=3D"http://bibfram=
e.org/vocab/" target=3D"_blank">
http://bibframe.org/vocab/</a><br>
&gt;<br>
&gt; - &nbsp;Added BIBFRAME example snippets in vocabulary section: e.g. <a=
 href=3D"http://bibframe.org/vocab/class-lcc" target=3D"_blank">
http://bibframe.org/vocab/class-lcc</a><br>
&gt;<br>
&gt; - &nbsp;Improved the MARC-to-BIBFRAME code: <a href=3D"http://bibframe=
.org/tools/" target=3D"_blank">
http://bibframe.org/tools/</a><br>
&gt;<br>
&gt; - &nbsp;Added a set of Frequently Asked Questions: <a href=3D"http://b=
ibframe.org/faq/" target=3D"_blank">
http://bibframe.org/faq/</a><br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; We have made every effort to update the MARC-to-BIBFRAME transformatio=
n code after modifying the vocabulary, and we plan to change and enhance th=
e code based on feedback from the papers. &nbsp;You can begin using the tra=
nsformation code today as a reference and
 starting point for your own explorations. &nbsp;See the contribute page to=
 learn more:
<a href=3D"http://bibframe.org/contribute/" target=3D"_blank">http://bibfra=
me.org/contribute/</a>.<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; Please read the papers that we are be putting up on <a href=3D"http://=
bibframe.org" target=3D"_blank">
bibframe.org</a> and participate in the discussion -- we are all in this to=
gether!<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; Sally<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; **************************<br>
&gt;<br>
&gt; Sally H. McCallum<br>
&gt;<br>
&gt; Chief, Network Development and Standards Office<br>
&gt;<br>
&gt; Library of Congress, &nbsp;101 Independence Ave., SE<br>
&gt;<br>
&gt; Washington, DC 20540 &nbsp;USA<br>
&gt;<br>
&gt; <a href=3D"mailto:[log in to unmask]" target=3D"_blank">[log in to unmask]</a><br>
&gt;<br>
&gt; Tel. <a href=3D"tel:1-202-707-5119" target=3D"_blank">1-202-707-5119</=
a> -- Fax <a href=3D"tel:1-202-707-0115" target=3D"_blank">
1-202-707-0115</a><br>
&gt;<br>
&gt; **************************<br>
&gt;<br>
&gt; &nbsp;<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_768F135D8DFF3A4A9E4BFF0549723FD953C51B7CILEXM02CorpExli_--

------------------------------

Date:    Sun, 5 May 2013 08:58:56 -0400
From:    "Young,Jeff (OR)" <[log in to unmask]>
Subject: Re: Documents and improvements

--Apple-Mail-A89924D3-F270-4728-B648-253390E0E332
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64

SSB0aGluayB0aGF0IFNLT1MgaXMgYW4gaW50ZXJlc3RpbmcgaWxsdXN0cmF0aW9uLiBUaGV5IGNv
dWxkIGhhdmUgdXNlZCByZWlmaWNhdGlvbiBvciBuYW1lZCBncmFwaHMgb3IgaW52ZW50ZWQgc29t
ZSBmbGF2b3Igb2YgQW5ub3RhdGlvbiB0byBzcGVjaWZ5IHRoZWlyIHN0cnVjdHVyZXMsIGJ1dCB0
aGV5IGNob3NlIHRvIGRvIGl0IHdpdGggc3RyYWlnaHQgUkRGIGluc3RlYWQuIFJhdGhlciB0aGFu
IGFzc3VtZSBSREYgaXNuJ3QgY2FwYWJsZSBvZiB0aGlzIG9yIGRlY2lkaW5nIGl0cyBub3QgaWRl
YWwgaW4gdGhhdCBmb3JtLCB0aGV5IGp1c3QgYml0IHRoZSBidWxsZXQgYW5kIGRpZCB0aGUgbW9k
ZWxpbmcgbmVlZGVkIHRvIG1ha2UgaXQgaGFwcGVuLiBJIGxpa2UgdGhhdCBhYm91dCBTS09TLg0K
DQpKZWZmDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCk9uIE1heSA1LCAyMDEzLCBhdCA2OjEyIEFN
LCAiU2hsb21vIFNhbmRlcnMiIDxTaGxvbW8uU2FuZGVyc0BFWExJQlJJU0dST1VQLkNPTT4gd3Jv
dGU6DQoNCj4gSSBhZ3JlZSB3aXRoIEplZmYgMTAwJS4NCj4gSW5zdGVhZCBvZiBjb25zb2xpZGF0
aW5nIG1vcmUgYW5kIG1vcmUgc3R1ZmYgYXJlIGRlZmluZWQuDQo+IEFsbCBmb3IgZ29vZCByZWFz
b25zLCBidXQgdGhlIGJvdHRvbSBsaW5lIHdpbGwgYmUgbG9uZ2VyIGZvciB2ZW5kb3JzIHRvIHN1
cHBvcnQsIG1vcmUgYnVnc+KApi4uDQo+ICANCj4gVGhhbmtzLA0KPiBTaGxvbW8NCj4gIA0KPiBF
eHBlcmllbmNlIHRoZSBhbGwtbmV3LCBzaW5naW5nIGFuZCBkYW5jaW5nIGludGVyYWN0aXZlIFBy
aW1vIGJyb2NodXJlDQo+ICANCj4gRnJvbTogQmlibGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJhbnNp
dGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVl0g
T24gQmVoYWxmIE9mIFJvYmVydCBTYW5kZXJzb24NCj4gU2VudDogU3VuZGF5LCBNYXkgMDUsIDIw
MTMgMTE6NTENCj4gVG86IEJJQkZSQU1FQExJU1RTRVJWLkxPQy5HT1YNCj4gU3ViamVjdDogUmU6
IFtCSUJGUkFNRV0gRG9jdW1lbnRzIGFuZCBpbXByb3ZlbWVudHMNCj4gIA0KPiAgDQo+IFNobG9t
bywNCj4gIA0KPiBZb3Ugd2VyZW4ndCBzYXRpc2ZpZWQgd2l0aCB0aGUgZXhwbGFuYXRpb24gZ2l2
ZW4gYXMgdG8gd2h5IHRoaXMgaXMgbm90IHRoZSBjYXNlPw0KPiAgDQo+IFJvYg0KPiAgDQo+IA0K
PiBPbiBTdW4sIE1heSA1LCAyMDEzIGF0IDEwOjE4IEFNLCBTaGxvbW8gU2FuZGVycyA8U2hsb21v
LlNhbmRlcnNAZXhsaWJyaXNncm91cC5jb20+IHdyb3RlOg0KPiBIZWFyLCBoZWFyDQo+ICANCj4g
VGhhbmtzLA0KPiBTaGxvbW8NCj4gIA0KPiBFeHBlcmllbmNlIHRoZSBhbGwtbmV3LCBzaW5naW5n
IGFuZCBkYW5jaW5nIGludGVyYWN0aXZlIFByaW1vIGJyb2NodXJlDQo+ICANCj4gRnJvbTogQmli
bGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJhbnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86
QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVl0gT24gQmVoYWxmIE9mIFlvdW5nLEplZmYgKE9SKQ0K
PiBTZW50OiBTYXR1cmRheSwgTWF5IDA0LCAyMDEzIDA2OjI3DQo+IFRvOiBCSUJGUkFNRUBMSVNU
U0VSVi5MT0MuR09WDQo+IFN1YmplY3Q6IFJlOiBbQklCRlJBTUVdIERvY3VtZW50cyBhbmQgaW1w
cm92ZW1lbnRzDQo+ICANCj4gQXMgS2FyZW4gQ295bGUgc3VnZ2VzdGVkIChpZiBJIHNraW1tZWQg
aGVyIHJlY2VudCBjb21tZW50cyBjb3JyZWN0bHkpLCB3aGF0IGlmIHlvdSBndXlzIGNhbid0IGFn
cmVlIGJlY2F1c2UgeW91J3JlIGJvdGggbWVyZWx5IHJlaW52ZW50aW5nIFJERiBncmFwaHM/DQo+
ICANCj4gSmVmZg0KPiANCj4gU2VudCBmcm9tIG15IGlQYWQNCj4gDQo+IE9uIE1heSAzLCAyMDEz
LCBhdCA0OjE2IFBNLCAiUm9iZXJ0IFNhbmRlcnNvbiIgPGF6YXJvdGg0MkBHTUFJTC5DT00+IHdy
b3RlOg0KPiANCj4gIA0KPiBEZWFyIFNhbGx5LCBSYXkgYW5kIGFsbCwNCj4gDQo+IEFzIGNvLWNo
YWlycyBhbmQgY28tZWRpdG9ycyBvZiB0aGUgVzNDIE9wZW4gQW5ub3RhdGlvbiBDb21tdW5pdHkg
R3JvdXAsIFBhb2xvLCBIZXJiZXJ0IGFuZCBJIHdvdWxkIGFnYWluIGxpa2UgdG8gaW52aXRlIG1l
bWJlcnMgb2YgdGhlIEJJQkZSQU1FIGdyb3VwIHRvIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIG9m
IGludGVyb3BlcmFibGUgYW5ub3RhdGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGZvciB0aGUgVzND
IENvbW11bml0eSBHcm91cC4gVGhlcmUgaXMgbmVpdGhlciBhIGNvc3Qgbm9yIG1lbWJlcnNoaXAg
cmVxdWlyZW1lbnQgdG8gam9pbmluZy4NCj4gDQo+IFdlIGZlZWwgaXQgaXMgZmFpciB0byBzYXkg
dGhhdCB0aGUgT3BlbiBBbm5vdGF0aW9uIGVmZm9ydCBoYXMgZ2FpbmVkIHNpZ25pZmljYW50IG1v
bWVudHVtLCBiZWluZyB0aGUgNnRoIGxhcmdlc3QgY29tbXVuaXR5IGdyb3VwIHdpdGggbWFueSBh
Y3RpdmUgYW5kIG9uZ29pbmcgZGlzY3Vzc2lvbnMuIEhvd2V2ZXIgdGhlcmUgaXMgYWx3YXlzIHJv
b20gZm9yIGltcHJvdmVtZW50LCBhbmQgd2Ugc3RpbGwgYmVsaWV2ZSB0aGF0IGJvdGggQklCRlJB
TUUgYW5kIE9wZW4gQW5ub3RhdGlvbiB3b3VsZCBiZW5lZml0IGZyb20gYW4gb3BlbiBkaXNjdXNz
aW9uIG9mIHRoZSBpc3N1ZXMgdGhhdCByZXN1bHRlZCBpbiB0aGUgZGl2ZXJnZW5jZSB3aGljaCBp
cyBjbGVhciBpbiB0aGUgYW5ub3RhdGlvbiBkb2N1bWVudC4NCj4gDQo+IEl0IGlzIHJlZ3JldHRh
YmxlIHRoYXQgdGhlIEJJQkZSQU1FIGFubm90YXRpb24gbW9kZWwgaXMgbmVpdGhlciBjb21wYXRp
YmxlIG5vciBpbnRlcm9wZXJhYmxlIHdpdGggdGhlIE9wZW4gQW5ub3RhdGlvbiBEYXRhIE1vZGVs
LCBlc3BlY2lhbGx5IGdpdmVuIHRoZSBzaWduaWZpY2FudCBvdmVybGFwIGJldHdlZW4gdGhlIHRh
cmdldCBjb21tdW5pdGllcyBvZiBPcGVuIEFubm90YXRpb24gYW5kIEJJQkZSQU1FLiAgV2UgYXJl
IGRpc2FwcG9pbnRlZCB0aGF0IHByaW9yIGVmZm9ydHMgdG8gZW5nYWdlIHdpdGggdGhlIEJJQkZS
QU1FIGNvbW11bml0eSByZWdhcmRpbmcgYW5ub3RhdGlvbiBkaWQgbm90IHlpZWxkIG1vcmUgY29u
c3RydWN0aXZlIHJlc3VsdHMgdG8gdGhpcyBzdGFnZS4gV2UgaG9wZSB0aGF0IG91ciBpbnZpdGF0
aW9uIHRvIGRpc2N1c3MgaXNzdWVzIG9uIHRoZSBXM0MgQ29tbXVuaXR5IEdyb3VwIHdpbGwgYmUg
bWV0IHBvc2l0aXZlbHkgYXMgd2UgZmVlbCB3ZSBvd2UgaXQgdG8gb3VyIGNvbW11bml0aWVzIHRv
IHdvcmsgdG93YXJkcyBjb252ZXJnZW5jZS4NCj4gDQo+IFJlc3BlY3RmdWxseSwNCj4gDQo+IFJv
YmVydCBTYW5kZXJzb24sIFBhb2xvIENpY2NhcmVzZSwgYW5kIEhlcmJlcnQgVmFuIGRlIFNvbXBl
bA0KPiANCj4gDQo+IA0KPiBPbiBGcmksIE1heSAzLCAyMDEzIGF0IDEyOjA4IEFNLCBNY0NhbGx1
bSwgU2FsbHkgPHNtY2NAbG9jLmdvdj4gd3JvdGU6DQo+ID4NCj4gPiBUaGFua3MgdG8gYWxsIGZv
ciB5b3VyIGNvbW1lbnRzIGFuZCBpZGVhcyBvdmVyIHRoZSBsYXN0IGZldyBtb250aHMuICBUaGUg
c21hbGwgdGVhbSB0aGF0IHdlIGhhdmUgY2FsbGVkIHRoZSBFYXJseSBFeHBlcmltZW50ZXJzIGhh
cyBwcmVwYXJlZCBzb21lIGRpc2N1c3Npb24gcGFwZXJzIG9uIGRpZmZpY3VsdCB0b3BpY3MgcmVs
YXRlZCB0byB0aGUgQklCRlJBTUUgbW9kZWwgYW5kIHRoZSBkZXZlbG9waW5nIGRyYWZ0IHZvY2Fi
dWxhcnkuICBOb3cgd2Ugd2FudCB0byBwdXQgdGhlc2UgcGFwZXJzIG9uIGJpYmZyYW1lLm9yZyBh
bmQgYmVnaW4gZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3RzZXJ2LiAgIEJ5IHByZXBhcmluZyBiYWNr
Z3JvdW5kIGFuZCByZWNvbW1lbmRhdGlvbiBwYXBlcnMgd2UgaG9wZSB0byBoZWxwIGZvY3VzIHRo
ZSBkaXNjdXNzaW9uIG9uIHRoZSBpc3N1ZXMuIA0KPiA+DQo+ID4gIA0KPiA+DQo+ID4gVGhlIGlz
c3VlcyBhcmUgc29tZSBvZiB0aGUgaGFyZCBvbmVzIHRoYXQgYWxsIG9mIHVzIHdobyBkZWFsIHdp
dGggYmlibGlvZ3JhcGhpYyBkYXRhIHJ1biBpbnRvICAtLSBhbHdheXMuICAgV2UgYXJlIHN0YXJ0
aW5nIHdpdGggdGhlIEJJQkZSQU1FIEFubm90YXRpb25zIHBhcGVyLCB3aGljaCB5b3UgY2FuIGZp
bmQgaGVyZToNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBodHRwOi8vYmliZnJhbWUub3JnL2Rv
Y3VtZW50YXRpb24vYW5ub3RhdGlvbnMNCj4gPg0KPiA+IFRoZW4gd2UgaG9wZSB0byBnZXQgZGlz
Y3Vzc2lvbiBwYXBlcnMgb24gQklCRlJBTUUgQXV0aG9yaXRpZXMsIFJlbGF0aW9uc2hpcHMsIFNj
aGVtYS5vcmcsIGFuZCBSZXNvdXJjZSB0eXBlcyBvdXQgc29vbiwgZm9sbG93ZWQgYnkgSG9sZGlu
Z3MsIEFnZ3JlZ2F0ZXMsIGFuZCBvdGhlciBpc3N1ZXMuICAgVGhlc2Ugd2VyZSBwcmVwYXJlZCBi
eSB2YXJpb3VzIHN1Ymdyb3VwcyBvZiB0aGUgRXhwZXJpbWVudGVyIHRlYW0uICBXZSBkbyBub3Qg
d2FudCB0byBzZW5kIGV2ZXJ5dGhpbmcgYXQgb25jZSBhcyB3ZSB3b3VsZCBsaWtlIHlvdSB0byBo
YXZlIGZvY3VzIHJhdGhlciB0aGFuIG92ZXJsb2FkLg0KPiA+DQo+ID4gIA0KPiA+DQo+ID4gV2Ug
YXNrIHRoYXQgd2hlbiBkaXNjdXNzaW5nIHRoZSB0b3BpY3MsIHlvdSBuYW1lIHlvdXIgbGlzdHNl
cnYgY29tbWVudCB3aXRoIHRoZSB0b3BpYyBzaG9ydCB0aXRsZSAoaW5kaWNhdGVkIG9uIHRoZSB0
b3BpYyBwYXBlcikgd2l0aCBhbiBleHRyYSB0aXRsZSB0byBiaW5kIHRocmVhZHMsIGUuZy4sICJh
bm5vdGF0aW9ucy0tbWFpbiBwb2ludCIuDQo+ID4NCj4gPiAgDQo+ID4NCj4gPiBXZSBhdCBMQyBj
b250aW51ZSB0byB3b3JrIG9uIHRoZSBjb252ZXJzaW9uIG9mIE1BUkMgZGF0YSwgd2hpY2gsIGFs
b25nIHdpdGggUkRBLCBpcyB0aGUgY3VycmVudCBmZWVkZXIgb2YgdGhlIGN1cnJlbnQgdm9jYWJ1
bGFyeSBhdmFpbGFibGUgYXQgaHR0cDovL2JpYmZyYW1lLm9yZy8uICBJbiB0aGUgbGFzdCBjb3Vw
bGUgb2YgbW9udGhzLCB3ZSBoYXZlIG1hZGUgdGhlIGZvbGxvd2luZyBlbmhhbmNlbWVudHMgdG8g
dGhlIEJJQkZSQU1FIHdlYnNpdGU6DQo+ID4NCj4gPiAgDQo+ID4NCj4gPiAtICBSZWd1bGFybHkg
dXBkYXRlZCB0byB0aGUgdm9jYWJ1bGFyeTogaHR0cDovL2JpYmZyYW1lLm9yZy92b2NhYi8NCj4g
Pg0KPiA+IC0gIEFkZGVkIEJJQkZSQU1FIGV4YW1wbGUgc25pcHBldHMgaW4gdm9jYWJ1bGFyeSBz
ZWN0aW9uOiBlLmcuIGh0dHA6Ly9iaWJmcmFtZS5vcmcvdm9jYWIvY2xhc3MtbGNjDQo+ID4NCj4g
PiAtICBJbXByb3ZlZCB0aGUgTUFSQy10by1CSUJGUkFNRSBjb2RlOiBodHRwOi8vYmliZnJhbWUu
b3JnL3Rvb2xzLw0KPiA+DQo+ID4gLSAgQWRkZWQgYSBzZXQgb2YgRnJlcXVlbnRseSBBc2tlZCBR
dWVzdGlvbnM6IGh0dHA6Ly9iaWJmcmFtZS5vcmcvZmFxLw0KPiA+DQo+ID4gIA0KPiA+DQo+ID4g
V2UgaGF2ZSBtYWRlIGV2ZXJ5IGVmZm9ydCB0byB1cGRhdGUgdGhlIE1BUkMtdG8tQklCRlJBTUUg
dHJhbnNmb3JtYXRpb24gY29kZSBhZnRlciBtb2RpZnlpbmcgdGhlIHZvY2FidWxhcnksIGFuZCB3
ZSBwbGFuIHRvIGNoYW5nZSBhbmQgZW5oYW5jZSB0aGUgY29kZSBiYXNlZCBvbiBmZWVkYmFjayBm
cm9tIHRoZSBwYXBlcnMuICBZb3UgY2FuIGJlZ2luIHVzaW5nIHRoZSB0cmFuc2Zvcm1hdGlvbiBj
b2RlIHRvZGF5IGFzIGEgcmVmZXJlbmNlIGFuZCBzdGFydGluZyBwb2ludCBmb3IgeW91ciBvd24g
ZXhwbG9yYXRpb25zLiAgU2VlIHRoZSBjb250cmlidXRlIHBhZ2UgdG8gbGVhcm4gbW9yZTogaHR0
cDovL2JpYmZyYW1lLm9yZy9jb250cmlidXRlLy4NCj4gPg0KPiA+ICANCj4gPg0KPiA+IFBsZWFz
ZSByZWFkIHRoZSBwYXBlcnMgdGhhdCB3ZSBhcmUgYmUgcHV0dGluZyB1cCBvbiBiaWJmcmFtZS5v
cmcgYW5kIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNzaW9uIC0tIHdlIGFyZSBhbGwgaW4gdGhp
cyB0b2dldGhlciENCj4gPg0KPiA+ICANCj4gPg0KPiA+IFNhbGx5DQo+ID4NCj4gPiAgDQo+ID4N
Cj4gPiAqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+DQo+ID4gU2FsbHkgSC4gTWNDYWxs
dW0NCj4gPg0KPiA+IENoaWVmLCBOZXR3b3JrIERldmVsb3BtZW50IGFuZCBTdGFuZGFyZHMgT2Zm
aWNlDQo+ID4NCj4gPiBMaWJyYXJ5IG9mIENvbmdyZXNzLCAgMTAxIEluZGVwZW5kZW5jZSBBdmUu
LCBTRQ0KPiA+DQo+ID4gV2FzaGluZ3RvbiwgREMgMjA1NDAgIFVTQQ0KPiA+DQo+ID4gc21jY0Bs
b2MuZ292DQo+ID4NCj4gPiBUZWwuIDEtMjAyLTcwNy01MTE5IC0tIEZheCAxLTIwMi03MDctMDEx
NQ0KPiA+DQo+ID4gKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPg0KPiA+ICANCj4gIA0K

--Apple-Mail-A89924D3-F270-4728-B648-253390E0E332
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSB0aGlu
ayB0aGF0IFNLT1MgaXMgYW4gaW50ZXJlc3RpbmcgaWxsdXN0cmF0aW9uLiBUaGV5IGNvdWxkIGhh
dmUgdXNlZCByZWlmaWNhdGlvbiBvciBuYW1lZCBncmFwaHMgb3IgaW52ZW50ZWQgc29tZSBmbGF2
b3Igb2YgQW5ub3RhdGlvbiB0byBzcGVjaWZ5IHRoZWlyIHN0cnVjdHVyZXMsIGJ1dCB0aGV5IGNo
b3NlIHRvIGRvIGl0IHdpdGggc3RyYWlnaHQgUkRGIGluc3RlYWQuIFJhdGhlciB0aGFuIGFzc3Vt
ZSBSREYgaXNuJ3QgY2FwYWJsZSBvZiB0aGlzIG9yIGRlY2lkaW5nIGl0cyBub3QgaWRlYWwgaW4g
dGhhdCBmb3JtLCB0aGV5IGp1c3QgYml0IHRoZSBidWxsZXQgYW5kIGRpZCB0aGUgbW9kZWxpbmcg
bmVlZGVkIHRvIG1ha2UgaXQgaGFwcGVuLiBJIGxpa2UgdGhhdCBhYm91dCBTS09TLjwvZGl2Pjxk
aXY+PGJyPjwvZGl2PjxkaXY+SmVmZjxicj48YnI+U2VudCBmcm9tIG15IGlQYWQ8L2Rpdj48ZGl2
Pjxicj5PbiBNYXkgNSwgMjAxMywgYXQgNjoxMiBBTSwgIlNobG9tbyBTYW5kZXJzIiAmbHQ7PGEg
aHJlZj0ibWFpbHRvOlNobG9tby5TYW5kZXJzQEVYTElCUklTR1JPVVAuQ09NIj5TaGxvbW8uU2Fu
ZGVyc0BFWExJQlJJU0dST1VQLkNPTTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl
IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPG1ldGEgbmFtZT0iR2Vu
ZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8
c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0
O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk
aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z
b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh
bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N
CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu
IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNl
Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv
Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh
eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv
bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCg0KDQo8ZGl2IGNsYXNzPSJXb3JkU2Vj
dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBKZWZmIDEwMCUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkluc3RlYWQgb2YgY29uc29saWRhdGluZyBtb3JlIGFuZCBtb3JlIHN0dWZm
IGFyZSBkZWZpbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbGwgZm9yIGdvb2Qg
cmVhc29ucywgYnV0IHRoZSBib3R0b20gbGluZSB3aWxsIGJlIGxvbmdlciBmb3IgdmVuZG9ycyB0
byBzdXBwb3J0LCBtb3JlIGJ1Z3PigKYuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5TaGxvbW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV4cGVyaWVuY2UgdGhlIGFsbC1uZXcs
IHNpbmdpbmcgYW5kIGRhbmNpbmcgaW50ZXJhY3RpdmUNCjxhIGhyZWY9Imh0dHA6Ly93d3cuZXhs
aWJyaXNwdWJsaWNhdGlvbnMuY29tL3ByaW1vLyI+UHJpbW8gYnJvY2h1cmU8L2E+IDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmlibGlvZ3JhcGhpYyBGcmFtZXdv
cmsgVHJhbnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFs8YSBocmVmPSJtYWlsdG86QklCRlJBTUVA
TElTVFNFUlYuTE9DLkdPViI+bWFpbHRvOkJJQkZSQU1FQExJU1RTRVJWLkxPQy5HT1Y8L2E+XQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgU2FuZGVyc29uPGJyPg0KPGI+U2VudDo8L2I+IFN1
bmRheSwgTWF5IDA1LCAyMDEzIDExOjUxPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86
QklCRlJBTUVATElTVFNFUlYuTE9DLkdPViI+QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVjwvYT48
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtCSUJGUkFNRV0gRG9jdW1lbnRzIGFuZCBpbXByb3Zl
bWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaGxvbW8sPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSB3ZXJlbid0IHNh
dGlzZmllZCB3aXRoIHRoZSBleHBsYW5hdGlvbiBnaXZlbiBhcyB0byB3aHkgdGhpcyBpcyBub3Qg
dGhlIGNhc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlJvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgTWF5IDUsIDIwMTMg
YXQgMTA6MTggQU0sIFNobG9tbyBTYW5kZXJzICZsdDs8YSBocmVmPSJtYWlsdG86U2hsb21vLlNh
bmRlcnNAZXhsaWJyaXNncm91cC5jb20iIHRhcmdldD0iX2JsYW5rIj5TaGxvbW8uU2FuZGVyc0Bl
eGxpYnJpc2dyb3VwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5IZWFyLCBoZWFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGxvbW88L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FeHBlcmll
bmNlIHRoZSBhbGwtbmV3LCBzaW5naW5nIGFuZCBkYW5jaW5nIGludGVyYWN0aXZlDQo8YSBocmVm
PSJodHRwOi8vd3d3LmV4bGlicmlzcHVibGljYXRpb25zLmNvbS9wcmltby8iIHRhcmdldD0iX2Js
YW5rIj5QcmltbyBicm9jaHVyZTwvYT4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
IEJpYmxpb2dyYXBoaWMgRnJhbWV3b3JrIFRyYW5zaXRpb24NCiBJbml0aWF0aXZlIEZvcnVtIFtt
YWlsdG86PGEgaHJlZj0ibWFpbHRvOkJJQkZSQU1FQExJU1RTRVJWLkxPQy5HT1YiIHRhcmdldD0i
X2JsYW5rIj5CSUJGUkFNRUBMSVNUU0VSVi5MT0MuR09WPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+WW91bmcsSmVmZiAoT1IpPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXkgMDQsIDIw
MTMgMDY6Mjc8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpCSUJGUkFNRUBMSVNUU0VS
Vi5MT0MuR09WIiB0YXJnZXQ9Il9ibGFuayI+QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVjwvYT48
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtCSUJGUkFNRV0gRG9jdW1lbnRzIGFuZCBpbXByb3Zl
bWVudHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgS2FyZW4gQ295bGUgc3VnZ2VzdGVkIChpZiBJIHNraW1t
ZWQgaGVyIHJlY2VudCBjb21tZW50cyBjb3JyZWN0bHkpLCB3aGF0IGlmIHlvdSBndXlzIGNhbid0
IGFncmVlIGJlY2F1c2UgeW91J3JlIGJvdGggbWVyZWx5IHJlaW52ZW50aW5nIFJERiBncmFwaHM/
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5KZWZmPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQYWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWF5IDMsIDIwMTMsIGF0IDQ6MTYg
UE0sICJSb2JlcnQgU2FuZGVyc29uIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmF6YXJvdGg0MkBHTUFJ
TC5DT00iIHRhcmdldD0iX2JsYW5rIj5hemFyb3RoNDJAR01BSUwuQ09NPC9hPiZndDsgd3JvdGU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5EZWFyIFNhbGx5LCBSYXkgYW5kIGFsbCw8YnI+DQo8YnI+DQpBcyBjby1jaGFp
cnMgYW5kIGNvLWVkaXRvcnMgb2YgdGhlIFczQyBPcGVuIEFubm90YXRpb24gQ29tbXVuaXR5IEdy
b3VwLCBQYW9sbywgSGVyYmVydCBhbmQgSSB3b3VsZCBhZ2FpbiBsaWtlIHRvIGludml0ZSBtZW1i
ZXJzIG9mIHRoZSBCSUJGUkFNRSBncm91cCB0byBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvZiBp
bnRlcm9wZXJhYmxlIGFubm90YXRpb24gb24gdGhlIG1haWxpbmcgbGlzdCBmb3IgdGhlIFczQyBD
b21tdW5pdHkgR3JvdXAuIFRoZXJlDQogaXMgbmVpdGhlciBhIGNvc3Qgbm9yIG1lbWJlcnNoaXAg
cmVxdWlyZW1lbnQgdG8gam9pbmluZy48YnI+DQo8YnI+DQpXZSBmZWVsIGl0IGlzIGZhaXIgdG8g
c2F5IHRoYXQgdGhlIE9wZW4gQW5ub3RhdGlvbiBlZmZvcnQgaGFzIGdhaW5lZCBzaWduaWZpY2Fu
dCBtb21lbnR1bSwgYmVpbmcgdGhlIDZ0aCBsYXJnZXN0IGNvbW11bml0eSBncm91cCB3aXRoIG1h
bnkgYWN0aXZlIGFuZCBvbmdvaW5nIGRpc2N1c3Npb25zLiBIb3dldmVyIHRoZXJlIGlzIGFsd2F5
cyByb29tIGZvciBpbXByb3ZlbWVudCwgYW5kIHdlIHN0aWxsIGJlbGlldmUgdGhhdCBib3RoIEJJ
QkZSQU1FDQogYW5kIE9wZW4gQW5ub3RhdGlvbiB3b3VsZCBiZW5lZml0IGZyb20gYW4gb3BlbiBk
aXNjdXNzaW9uIG9mIHRoZSBpc3N1ZXMgdGhhdCByZXN1bHRlZCBpbiB0aGUgZGl2ZXJnZW5jZSB3
aGljaCBpcyBjbGVhciBpbiB0aGUgYW5ub3RhdGlvbiBkb2N1bWVudC48YnI+DQo8YnI+DQpJdCBp
cyByZWdyZXR0YWJsZSB0aGF0IHRoZSBCSUJGUkFNRSBhbm5vdGF0aW9uIG1vZGVsIGlzIG5laXRo
ZXIgY29tcGF0aWJsZSBub3IgaW50ZXJvcGVyYWJsZSB3aXRoIHRoZSBPcGVuIEFubm90YXRpb24g
RGF0YSBNb2RlbCwgZXNwZWNpYWxseSBnaXZlbiB0aGUgc2lnbmlmaWNhbnQgb3ZlcmxhcCBiZXR3
ZWVuIHRoZSB0YXJnZXQgY29tbXVuaXRpZXMgb2YgT3BlbiBBbm5vdGF0aW9uIGFuZCBCSUJGUkFN
RS4gJm5ic3A7V2UgYXJlIGRpc2FwcG9pbnRlZCB0aGF0DQogcHJpb3IgZWZmb3J0cyB0byBlbmdh
Z2Ugd2l0aCB0aGUgQklCRlJBTUUgY29tbXVuaXR5IHJlZ2FyZGluZyBhbm5vdGF0aW9uIGRpZCBu
b3QgeWllbGQgbW9yZSBjb25zdHJ1Y3RpdmUgcmVzdWx0cyB0byB0aGlzIHN0YWdlLiBXZSBob3Bl
IHRoYXQgb3VyIGludml0YXRpb24gdG8gZGlzY3VzcyBpc3N1ZXMgb24gdGhlIFczQyBDb21tdW5p
dHkgR3JvdXAgd2lsbCBiZSBtZXQgcG9zaXRpdmVseSBhcyB3ZSBmZWVsIHdlIG93ZSBpdCB0byBv
dXIgY29tbXVuaXRpZXMNCiB0byB3b3JrIHRvd2FyZHMgY29udmVyZ2VuY2UuPGJyPg0KPGJyPg0K
UmVzcGVjdGZ1bGx5LDxicj4NCjxicj4NClJvYmVydCBTYW5kZXJzb24sIFBhb2xvIENpY2NhcmVz
ZSwgYW5kIEhlcmJlcnQgVmFuIGRlIFNvbXBlbDxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIEZy
aSwgTWF5IDMsIDIwMTMgYXQgMTI6MDggQU0sIE1jQ2FsbHVtLCBTYWxseSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnNtY2NAbG9jLmdvdiIgdGFyZ2V0PSJfYmxhbmsiPnNtY2NAbG9jLmdvdjwvYT4mZ3Q7
IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyB0byBhbGwgZm9yIHlvdXIgY29tbWVu
dHMgYW5kIGlkZWFzIG92ZXIgdGhlIGxhc3QgZmV3IG1vbnRocy4gJm5ic3A7VGhlIHNtYWxsIHRl
YW0gdGhhdCB3ZSBoYXZlIGNhbGxlZCB0aGUgRWFybHkgRXhwZXJpbWVudGVycyBoYXMgcHJlcGFy
ZWQgc29tZSBkaXNjdXNzaW9uIHBhcGVycyBvbiBkaWZmaWN1bHQgdG9waWNzIHJlbGF0ZWQgdG8g
dGhlIEJJQkZSQU1FIG1vZGVsIGFuZCB0aGUgZGV2ZWxvcGluZyBkcmFmdCB2b2NhYnVsYXJ5LiAm
bmJzcDtOb3cNCiB3ZSB3YW50IHRvIHB1dCB0aGVzZSBwYXBlcnMgb24gPGEgaHJlZj0iaHR0cDov
L2JpYmZyYW1lLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpYmZyYW1lLm9yZzwvYT4gYW5kIGJlZ2lu
IGRpc2N1c3Npb24gb24gdGhpcyBsaXN0c2Vydi4gJm5ic3A7IEJ5IHByZXBhcmluZyBiYWNrZ3Jv
dW5kIGFuZCByZWNvbW1lbmRhdGlvbiBwYXBlcnMgd2UgaG9wZSB0byBoZWxwIGZvY3VzIHRoZSBk
aXNjdXNzaW9uIG9uIHRoZSBpc3N1ZXMuDQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+
DQomZ3Q7PGJyPg0KJmd0OyBUaGUgaXNzdWVzIGFyZSBzb21lIG9mIHRoZSBoYXJkIG9uZXMgdGhh
dCBhbGwgb2YgdXMgd2hvIGRlYWwgd2l0aCBiaWJsaW9ncmFwaGljIGRhdGEgcnVuIGludG8gJm5i
c3A7LS0gYWx3YXlzLiAmbmJzcDsgV2UgYXJlIHN0YXJ0aW5nIHdpdGggdGhlIEJJQkZSQU1FIEFu
bm90YXRpb25zIHBhcGVyLCB3aGljaCB5b3UgY2FuIGZpbmQgaGVyZTo8YnI+DQomZ3Q7PGJyPg0K
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IDxhIGhyZWY9Imh0dHA6Ly9iaWJmcmFtZS5vcmcvZG9jdW1lbnRhdGlvbi9hbm5vdGF0aW9u
cyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2JpYmZyYW1lLm9yZy9kb2N1bWVudGF0aW9uL2Fu
bm90YXRpb25zPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZW4gd2UgaG9wZSB0byBnZXQgZGlz
Y3Vzc2lvbiBwYXBlcnMgb24gQklCRlJBTUUgQXV0aG9yaXRpZXMsIFJlbGF0aW9uc2hpcHMsIDxh
IGhyZWY9Imh0dHA6Ly9TY2hlbWEub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpTY2hlbWEub3JnPC9h
PiwgYW5kIFJlc291cmNlIHR5cGVzIG91dCBzb29uLCBmb2xsb3dlZCBieSBIb2xkaW5ncywgQWdn
cmVnYXRlcywgYW5kIG90aGVyIGlzc3Vlcy4gJm5ic3A7IFRoZXNlIHdlcmUgcHJlcGFyZWQgYnkg
dmFyaW91cyBzdWJncm91cHMgb2YgdGhlIEV4cGVyaW1lbnRlciB0ZWFtLiAmbmJzcDtXZSBkbyBu
b3Qgd2FudCB0byBzZW5kIGV2ZXJ5dGhpbmcgYXQgb25jZSBhcyB3ZSB3b3VsZCBsaWtlIHlvdSB0
byBoYXZlIGZvY3VzIHJhdGhlciB0aGFuIG92ZXJsb2FkLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZu
YnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGFzayB0aGF0IHdoZW4gZGlzY3Vzc2luZyB0aGUg
dG9waWNzLCB5b3UgbmFtZSB5b3VyIGxpc3RzZXJ2IGNvbW1lbnQgd2l0aCB0aGUgdG9waWMgc2hv
cnQgdGl0bGUgKGluZGljYXRlZCBvbiB0aGUgdG9waWMgcGFwZXIpIHdpdGggYW4gZXh0cmEgdGl0
bGUgdG8gYmluZCB0aHJlYWRzLCBlLmcuLCAiYW5ub3RhdGlvbnMtLW1haW4gcG9pbnQiLjxicj4N
CiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGF0IExDIGNvbnRp
bnVlIHRvIHdvcmsgb24gdGhlIGNvbnZlcnNpb24gb2YgTUFSQyBkYXRhLCB3aGljaCwgYWxvbmcg
d2l0aCBSREEsIGlzIHRoZSBjdXJyZW50IGZlZWRlciBvZiB0aGUgY3VycmVudCB2b2NhYnVsYXJ5
IGF2YWlsYWJsZSBhdA0KPGEgaHJlZj0iaHR0cDovL2JpYmZyYW1lLm9yZy8iIHRhcmdldD0iX2Js
YW5rIj5odHRwOi8vYmliZnJhbWUub3JnLzwvYT4uICZuYnNwO0luIHRoZSBsYXN0IGNvdXBsZSBv
ZiBtb250aHMsIHdlIGhhdmUgbWFkZSB0aGUgZm9sbG93aW5nIGVuaGFuY2VtZW50cyB0byB0aGUg
QklCRlJBTUUgd2Vic2l0ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJy
Pg0KJmd0OyAtICZuYnNwO1JlZ3VsYXJseSB1cGRhdGVkIHRvIHRoZSB2b2NhYnVsYXJ5OiA8YSBo
cmVmPSJodHRwOi8vYmliZnJhbWUub3JnL3ZvY2FiLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDov
L2JpYmZyYW1lLm9yZy92b2NhYi88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgLSAmbmJzcDtBZGRl
ZCBCSUJGUkFNRSBleGFtcGxlIHNuaXBwZXRzIGluIHZvY2FidWxhcnkgc2VjdGlvbjogZS5nLiA8
YSBocmVmPSJodHRwOi8vYmliZnJhbWUub3JnL3ZvY2FiL2NsYXNzLWxjYyIgdGFyZ2V0PSJfYmxh
bmsiPg0KaHR0cDovL2JpYmZyYW1lLm9yZy92b2NhYi9jbGFzcy1sY2M8L2E+PGJyPg0KJmd0Ozxi
cj4NCiZndDsgLSAmbmJzcDtJbXByb3ZlZCB0aGUgTUFSQy10by1CSUJGUkFNRSBjb2RlOiA8YSBo
cmVmPSJodHRwOi8vYmliZnJhbWUub3JnL3Rvb2xzLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDov
L2JpYmZyYW1lLm9yZy90b29scy88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgLSAmbmJzcDtBZGRl
ZCBhIHNldCBvZiBGcmVxdWVudGx5IEFza2VkIFF1ZXN0aW9uczogPGEgaHJlZj0iaHR0cDovL2Jp
YmZyYW1lLm9yZy9mYXEvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vYmliZnJhbWUub3JnL2Zh
cS88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4NCiZndDsgV2Ug
aGF2ZSBtYWRlIGV2ZXJ5IGVmZm9ydCB0byB1cGRhdGUgdGhlIE1BUkMtdG8tQklCRlJBTUUgdHJh
bnNmb3JtYXRpb24gY29kZSBhZnRlciBtb2RpZnlpbmcgdGhlIHZvY2FidWxhcnksIGFuZCB3ZSBw
bGFuIHRvIGNoYW5nZSBhbmQgZW5oYW5jZSB0aGUgY29kZSBiYXNlZCBvbiBmZWVkYmFjayBmcm9t
IHRoZSBwYXBlcnMuICZuYnNwO1lvdSBjYW4gYmVnaW4gdXNpbmcgdGhlIHRyYW5zZm9ybWF0aW9u
IGNvZGUgdG9kYXkgYXMgYSByZWZlcmVuY2UgYW5kDQogc3RhcnRpbmcgcG9pbnQgZm9yIHlvdXIg
b3duIGV4cGxvcmF0aW9ucy4gJm5ic3A7U2VlIHRoZSBjb250cmlidXRlIHBhZ2UgdG8gbGVhcm4g
bW9yZToNCjxhIGhyZWY9Imh0dHA6Ly9iaWJmcmFtZS5vcmcvY29udHJpYnV0ZS8iIHRhcmdldD0i
X2JsYW5rIj5odHRwOi8vYmliZnJhbWUub3JnL2NvbnRyaWJ1dGUvPC9hPi48YnI+DQomZ3Q7PGJy
Pg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2UgcmVhZCB0aGUgcGFwZXJz
IHRoYXQgd2UgYXJlIGJlIHB1dHRpbmcgdXAgb24gPGEgaHJlZj0iaHR0cDovL2JpYmZyYW1lLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KYmliZnJhbWUub3JnPC9hPiBhbmQgcGFydGljaXBhdGUgaW4g
dGhlIGRpc2N1c3Npb24gLS0gd2UgYXJlIGFsbCBpbiB0aGlzIHRvZ2V0aGVyITxicj4NCiZndDs8
YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7IFNhbGx5PGJyPg0KJmd0Ozxicj4N
CiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4NCiZndDsgKioqKioqKioqKioqKioqKioqKioqKioq
Kio8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTYWxseSBILiBNY0NhbGx1bTxicj4NCiZndDs8YnI+DQom
Z3Q7IENoaWVmLCBOZXR3b3JrIERldmVsb3BtZW50IGFuZCBTdGFuZGFyZHMgT2ZmaWNlPGJyPg0K
Jmd0Ozxicj4NCiZndDsgTGlicmFyeSBvZiBDb25ncmVzcywgJm5ic3A7MTAxIEluZGVwZW5kZW5j
ZSBBdmUuLCBTRTxicj4NCiZndDs8YnI+DQomZ3Q7IFdhc2hpbmd0b24sIERDIDIwNTQwICZuYnNw
O1VTQTxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpzbWNjQGxvYy5nb3YiIHRh
cmdldD0iX2JsYW5rIj5zbWNjQGxvYy5nb3Y8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGVsLiA8
YSBocmVmPSJ0ZWw6MS0yMDItNzA3LTUxMTkiIHRhcmdldD0iX2JsYW5rIj4xLTIwMi03MDctNTEx
OTwvYT4gLS0gRmF4IDxhIGhyZWY9InRlbDoxLTIwMi03MDctMDExNSIgdGFyZ2V0PSJfYmxhbmsi
Pg0KMS0yMDItNzA3LTAxMTU8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgKioqKioqKioqKioqKioq
KioqKioqKioqKio8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg==

--Apple-Mail-A89924D3-F270-4728-B648-253390E0E332--

------------------------------

Date:    Sun, 5 May 2013 13:40:05 +0000
From:    Shlomo Sanders <[log in to unmask]>
Subject: Re: Documents and improvements

--_000_768F135D8DFF3A4A9E4BFF0549723FD953C5211BILEXM02CorpExli_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXMgSSBzYWlkIHRoZSBsYXN0IHRpbWUuDQpJIGFncmVlIDEwMCUgd2l0aCBKZWZmLg0KDQpUaGFu
a3MsDQpTaGxvbW8gU2FuZGVycw0KQ1RPDQpFeCBMaWJyaXMNCg0KRXhwZXJpZW5jZSB0aGUgYWxs
LW5ldywgc2luZ2luZyBhbmQgZGFuY2luZyBpbnRlcmFjdGl2ZSBQcmltbyBicm9jaHVyZTxodHRw
Oi8vd3d3LmV4bGlicmlzcHVibGljYXRpb25zLmNvbS9wcmltby8+DQoNCkZyb206IEJpYmxpb2dy
YXBoaWMgRnJhbWV3b3JrIFRyYW5zaXRpb24gSW5pdGlhdGl2ZSBGb3J1bSBbbWFpbHRvOkJJQkZS
QU1FQExJU1RTRVJWLkxPQy5HT1ZdIE9uIEJlaGFsZiBPZiBZb3VuZyxKZWZmIChPUikNClNlbnQ6
IFN1bmRheSwgTWF5IDA1LCAyMDEzIDE1OjU5DQpUbzogQklCRlJBTUVATElTVFNFUlYuTE9DLkdP
Vg0KU3ViamVjdDogUmU6IFtCSUJGUkFNRV0gRG9jdW1lbnRzIGFuZCBpbXByb3ZlbWVudHMNCg0K
SSB0aGluayB0aGF0IFNLT1MgaXMgYW4gaW50ZXJlc3RpbmcgaWxsdXN0cmF0aW9uLiBUaGV5IGNv
dWxkIGhhdmUgdXNlZCByZWlmaWNhdGlvbiBvciBuYW1lZCBncmFwaHMgb3IgaW52ZW50ZWQgc29t
ZSBmbGF2b3Igb2YgQW5ub3RhdGlvbiB0byBzcGVjaWZ5IHRoZWlyIHN0cnVjdHVyZXMsIGJ1dCB0
aGV5IGNob3NlIHRvIGRvIGl0IHdpdGggc3RyYWlnaHQgUkRGIGluc3RlYWQuIFJhdGhlciB0aGFu
IGFzc3VtZSBSREYgaXNuJ3QgY2FwYWJsZSBvZiB0aGlzIG9yIGRlY2lkaW5nIGl0cyBub3QgaWRl
YWwgaW4gdGhhdCBmb3JtLCB0aGV5IGp1c3QgYml0IHRoZSBidWxsZXQgYW5kIGRpZCB0aGUgbW9k
ZWxpbmcgbmVlZGVkIHRvIG1ha2UgaXQgaGFwcGVuLiBJIGxpa2UgdGhhdCBhYm91dCBTS09TLg0K
DQpKZWZmDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCk9uIE1heSA1LCAyMDEzLCBhdCA2OjEyIEFN
LCAiU2hsb21vIFNhbmRlcnMiIDxTaGxvbW8uU2FuZGVyc0BFWExJQlJJU0dST1VQLkNPTTxtYWls
dG86U2hsb21vLlNhbmRlcnNARVhMSUJSSVNHUk9VUC5DT00+PiB3cm90ZToNCkkgYWdyZWUgd2l0
aCBKZWZmIDEwMCUuDQpJbnN0ZWFkIG9mIGNvbnNvbGlkYXRpbmcgbW9yZSBhbmQgbW9yZSBzdHVm
ZiBhcmUgZGVmaW5lZC4NCkFsbCBmb3IgZ29vZCByZWFzb25zLCBidXQgdGhlIGJvdHRvbSBsaW5l
IHdpbGwgYmUgbG9uZ2VyIGZvciB2ZW5kb3JzIHRvIHN1cHBvcnQsIG1vcmUgYnVnc+KApi4uDQoN
ClRoYW5rcywNClNobG9tbw0KDQpFeHBlcmllbmNlIHRoZSBhbGwtbmV3LCBzaW5naW5nIGFuZCBk
YW5jaW5nIGludGVyYWN0aXZlIFByaW1vIGJyb2NodXJlPGh0dHA6Ly93d3cuZXhsaWJyaXNwdWJs
aWNhdGlvbnMuY29tL3ByaW1vLz4NCg0KRnJvbTogQmlibGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJh
bnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9DLkdP
Vl0gT24gQmVoYWxmIE9mIFJvYmVydCBTYW5kZXJzb24NClNlbnQ6IFN1bmRheSwgTWF5IDA1LCAy
MDEzIDExOjUxDQpUbzogQklCRlJBTUVATElTVFNFUlYuTE9DLkdPVjxtYWlsdG86QklCRlJBTUVA
TElTVFNFUlYuTE9DLkdPVj4NClN1YmplY3Q6IFJlOiBbQklCRlJBTUVdIERvY3VtZW50cyBhbmQg
aW1wcm92ZW1lbnRzDQoNCg0KU2hsb21vLA0KDQpZb3Ugd2VyZW4ndCBzYXRpc2ZpZWQgd2l0aCB0
aGUgZXhwbGFuYXRpb24gZ2l2ZW4gYXMgdG8gd2h5IHRoaXMgaXMgbm90IHRoZSBjYXNlPw0KDQpS
b2INCg0KT24gU3VuLCBNYXkgNSwgMjAxMyBhdCAxMDoxOCBBTSwgU2hsb21vIFNhbmRlcnMgPFNo
bG9tby5TYW5kZXJzQGV4bGlicmlzZ3JvdXAuY29tPG1haWx0bzpTaGxvbW8uU2FuZGVyc0BleGxp
YnJpc2dyb3VwLmNvbT4+IHdyb3RlOg0KSGVhciwgaGVhcg0KDQpUaGFua3MsDQpTaGxvbW8NCg0K
RXhwZXJpZW5jZSB0aGUgYWxsLW5ldywgc2luZ2luZyBhbmQgZGFuY2luZyBpbnRlcmFjdGl2ZSBQ
cmltbyBicm9jaHVyZTxodHRwOi8vd3d3LmV4bGlicmlzcHVibGljYXRpb25zLmNvbS9wcmltby8+
DQoNCkZyb206IEJpYmxpb2dyYXBoaWMgRnJhbWV3b3JrIFRyYW5zaXRpb24gSW5pdGlhdGl2ZSBG
b3J1bSBbbWFpbHRvOkJJQkZSQU1FQExJU1RTRVJWLkxPQy5HT1Y8bWFpbHRvOkJJQkZSQU1FQExJ
U1RTRVJWLkxPQy5HT1Y+XSBPbiBCZWhhbGYgT2YgWW91bmcsSmVmZiAoT1IpDQpTZW50OiBTYXR1
cmRheSwgTWF5IDA0LCAyMDEzIDA2OjI3DQpUbzogQklCRlJBTUVATElTVFNFUlYuTE9DLkdPVjxt
YWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVj4NClN1YmplY3Q6IFJlOiBbQklCRlJBTUVd
IERvY3VtZW50cyBhbmQgaW1wcm92ZW1lbnRzDQoNCkFzIEthcmVuIENveWxlIHN1Z2dlc3RlZCAo
aWYgSSBza2ltbWVkIGhlciByZWNlbnQgY29tbWVudHMgY29ycmVjdGx5KSwgd2hhdCBpZiB5b3Ug
Z3V5cyBjYW4ndCBhZ3JlZSBiZWNhdXNlIHlvdSdyZSBib3RoIG1lcmVseSByZWludmVudGluZyBS
REYgZ3JhcGhzPw0KDQpKZWZmDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCk9uIE1heSAzLCAyMDEz
LCBhdCA0OjE2IFBNLCAiUm9iZXJ0IFNhbmRlcnNvbiIgPGF6YXJvdGg0MkBHTUFJTC5DT008bWFp
bHRvOmF6YXJvdGg0MkBHTUFJTC5DT00+PiB3cm90ZToNCg0KRGVhciBTYWxseSwgUmF5IGFuZCBh
bGwsDQoNCkFzIGNvLWNoYWlycyBhbmQgY28tZWRpdG9ycyBvZiB0aGUgVzNDIE9wZW4gQW5ub3Rh
dGlvbiBDb21tdW5pdHkgR3JvdXAsIFBhb2xvLCBIZXJiZXJ0IGFuZCBJIHdvdWxkIGFnYWluIGxp
a2UgdG8gaW52aXRlIG1lbWJlcnMgb2YgdGhlIEJJQkZSQU1FIGdyb3VwIHRvIGNvbnRpbnVlIHRo
ZSBkaXNjdXNzaW9uIG9mIGludGVyb3BlcmFibGUgYW5ub3RhdGlvbiBvbiB0aGUgbWFpbGluZyBs
aXN0IGZvciB0aGUgVzNDIENvbW11bml0eSBHcm91cC4gVGhlcmUgaXMgbmVpdGhlciBhIGNvc3Qg
bm9yIG1lbWJlcnNoaXAgcmVxdWlyZW1lbnQgdG8gam9pbmluZy4NCg0KV2UgZmVlbCBpdCBpcyBm
YWlyIHRvIHNheSB0aGF0IHRoZSBPcGVuIEFubm90YXRpb24gZWZmb3J0IGhhcyBnYWluZWQgc2ln
bmlmaWNhbnQgbW9tZW50dW0sIGJlaW5nIHRoZSA2dGggbGFyZ2VzdCBjb21tdW5pdHkgZ3JvdXAg
d2l0aCBtYW55IGFjdGl2ZSBhbmQgb25nb2luZyBkaXNjdXNzaW9ucy4gSG93ZXZlciB0aGVyZSBp
cyBhbHdheXMgcm9vbSBmb3IgaW1wcm92ZW1lbnQsIGFuZCB3ZSBzdGlsbCBiZWxpZXZlIHRoYXQg
Ym90aCBCSUJGUkFNRSBhbmQgT3BlbiBBbm5vdGF0aW9uIHdvdWxkIGJlbmVmaXQgZnJvbSBhbiBv
cGVuIGRpc2N1c3Npb24gb2YgdGhlIGlzc3VlcyB0aGF0IHJlc3VsdGVkIGluIHRoZSBkaXZlcmdl
bmNlIHdoaWNoIGlzIGNsZWFyIGluIHRoZSBhbm5vdGF0aW9uIGRvY3VtZW50Lg0KDQpJdCBpcyBy
ZWdyZXR0YWJsZSB0aGF0IHRoZSBCSUJGUkFNRSBhbm5vdGF0aW9uIG1vZGVsIGlzIG5laXRoZXIg
Y29tcGF0aWJsZSBub3IgaW50ZXJvcGVyYWJsZSB3aXRoIHRoZSBPcGVuIEFubm90YXRpb24gRGF0
YSBNb2RlbCwgZXNwZWNpYWxseSBnaXZlbiB0aGUgc2lnbmlmaWNhbnQgb3ZlcmxhcCBiZXR3ZWVu
IHRoZSB0YXJnZXQgY29tbXVuaXRpZXMgb2YgT3BlbiBBbm5vdGF0aW9uIGFuZCBCSUJGUkFNRS4g
IFdlIGFyZSBkaXNhcHBvaW50ZWQgdGhhdCBwcmlvciBlZmZvcnRzIHRvIGVuZ2FnZSB3aXRoIHRo
ZSBCSUJGUkFNRSBjb21tdW5pdHkgcmVnYXJkaW5nIGFubm90YXRpb24gZGlkIG5vdCB5aWVsZCBt
b3JlIGNvbnN0cnVjdGl2ZSByZXN1bHRzIHRvIHRoaXMgc3RhZ2UuIFdlIGhvcGUgdGhhdCBvdXIg
aW52aXRhdGlvbiB0byBkaXNjdXNzIGlzc3VlcyBvbiB0aGUgVzNDIENvbW11bml0eSBHcm91cCB3
aWxsIGJlIG1ldCBwb3NpdGl2ZWx5IGFzIHdlIGZlZWwgd2Ugb3dlIGl0IHRvIG91ciBjb21tdW5p
dGllcyB0byB3b3JrIHRvd2FyZHMgY29udmVyZ2VuY2UuDQoNClJlc3BlY3RmdWxseSwNCg0KUm9i
ZXJ0IFNhbmRlcnNvbiwgUGFvbG8gQ2ljY2FyZXNlLCBhbmQgSGVyYmVydCBWYW4gZGUgU29tcGVs
DQoNCg0KDQpPbiBGcmksIE1heSAzLCAyMDEzIGF0IDEyOjA4IEFNLCBNY0NhbGx1bSwgU2FsbHkg
PHNtY2NAbG9jLmdvdjxtYWlsdG86c21jY0Bsb2MuZ292Pj4gd3JvdGU6DQo+DQo+IFRoYW5rcyB0
byBhbGwgZm9yIHlvdXIgY29tbWVudHMgYW5kIGlkZWFzIG92ZXIgdGhlIGxhc3QgZmV3IG1vbnRo
cy4gIFRoZSBzbWFsbCB0ZWFtIHRoYXQgd2UgaGF2ZSBjYWxsZWQgdGhlIEVhcmx5IEV4cGVyaW1l
bnRlcnMgaGFzIHByZXBhcmVkIHNvbWUgZGlzY3Vzc2lvbiBwYXBlcnMgb24gZGlmZmljdWx0IHRv
cGljcyByZWxhdGVkIHRvIHRoZSBCSUJGUkFNRSBtb2RlbCBhbmQgdGhlIGRldmVsb3BpbmcgZHJh
ZnQgdm9jYWJ1bGFyeS4gIE5vdyB3ZSB3YW50IHRvIHB1dCB0aGVzZSBwYXBlcnMgb24gYmliZnJh
bWUub3JnPGh0dHA6Ly9iaWJmcmFtZS5vcmc+IGFuZCBiZWdpbiBkaXNjdXNzaW9uIG9uIHRoaXMg
bGlzdHNlcnYuICAgQnkgcHJlcGFyaW5nIGJhY2tncm91bmQgYW5kIHJlY29tbWVuZGF0aW9uIHBh
cGVycyB3ZSBob3BlIHRvIGhlbHAgZm9jdXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGlzc3Vlcy4N
Cj4NCj4NCj4NCj4gVGhlIGlzc3VlcyBhcmUgc29tZSBvZiB0aGUgaGFyZCBvbmVzIHRoYXQgYWxs
IG9mIHVzIHdobyBkZWFsIHdpdGggYmlibGlvZ3JhcGhpYyBkYXRhIHJ1biBpbnRvICAtLSBhbHdh
eXMuICAgV2UgYXJlIHN0YXJ0aW5nIHdpdGggdGhlIEJJQkZSQU1FIEFubm90YXRpb25zIHBhcGVy
LCB3aGljaCB5b3UgY2FuIGZpbmQgaGVyZToNCj4NCj4gICAgICAgICAgICAgICAgIGh0dHA6Ly9i
aWJmcmFtZS5vcmcvZG9jdW1lbnRhdGlvbi9hbm5vdGF0aW9ucw0KPg0KPiBUaGVuIHdlIGhvcGUg
dG8gZ2V0IGRpc2N1c3Npb24gcGFwZXJzIG9uIEJJQkZSQU1FIEF1dGhvcml0aWVzLCBSZWxhdGlv
bnNoaXBzLCBTY2hlbWEub3JnPGh0dHA6Ly9TY2hlbWEub3JnPiwgYW5kIFJlc291cmNlIHR5cGVz
IG91dCBzb29uLCBmb2xsb3dlZCBieSBIb2xkaW5ncywgQWdncmVnYXRlcywgYW5kIG90aGVyIGlz
c3Vlcy4gICBUaGVzZSB3ZXJlIHByZXBhcmVkIGJ5IHZhcmlvdXMgc3ViZ3JvdXBzIG9mIHRoZSBF
eHBlcmltZW50ZXIgdGVhbS4gIFdlIGRvIG5vdCB3YW50IHRvIHNlbmQgZXZlcnl0aGluZyBhdCBv
bmNlIGFzIHdlIHdvdWxkIGxpa2UgeW91IHRvIGhhdmUgZm9jdXMgcmF0aGVyIHRoYW4gb3Zlcmxv
YWQuDQo+DQo+DQo+DQo+IFdlIGFzayB0aGF0IHdoZW4gZGlzY3Vzc2luZyB0aGUgdG9waWNzLCB5
b3UgbmFtZSB5b3VyIGxpc3RzZXJ2IGNvbW1lbnQgd2l0aCB0aGUgdG9waWMgc2hvcnQgdGl0bGUg
KGluZGljYXRlZCBvbiB0aGUgdG9waWMgcGFwZXIpIHdpdGggYW4gZXh0cmEgdGl0bGUgdG8gYmlu
ZCB0aHJlYWRzLCBlLmcuLCAiYW5ub3RhdGlvbnMtLW1haW4gcG9pbnQiLg0KPg0KPg0KPg0KPiBX
ZSBhdCBMQyBjb250aW51ZSB0byB3b3JrIG9uIHRoZSBjb252ZXJzaW9uIG9mIE1BUkMgZGF0YSwg
d2hpY2gsIGFsb25nIHdpdGggUkRBLCBpcyB0aGUgY3VycmVudCBmZWVkZXIgb2YgdGhlIGN1cnJl
bnQgdm9jYWJ1bGFyeSBhdmFpbGFibGUgYXQgaHR0cDovL2JpYmZyYW1lLm9yZy8uICBJbiB0aGUg
bGFzdCBjb3VwbGUgb2YgbW9udGhzLCB3ZSBoYXZlIG1hZGUgdGhlIGZvbGxvd2luZyBlbmhhbmNl
bWVudHMgdG8gdGhlIEJJQkZSQU1FIHdlYnNpdGU6DQo+DQo+DQo+DQo+IC0gIFJlZ3VsYXJseSB1
cGRhdGVkIHRvIHRoZSB2b2NhYnVsYXJ5OiBodHRwOi8vYmliZnJhbWUub3JnL3ZvY2FiLw0KPg0K
PiAtICBBZGRlZCBCSUJGUkFNRSBleGFtcGxlIHNuaXBwZXRzIGluIHZvY2FidWxhcnkgc2VjdGlv
bjogZS5nLiBodHRwOi8vYmliZnJhbWUub3JnL3ZvY2FiL2NsYXNzLWxjYw0KPg0KPiAtICBJbXBy
b3ZlZCB0aGUgTUFSQy10by1CSUJGUkFNRSBjb2RlOiBodHRwOi8vYmliZnJhbWUub3JnL3Rvb2xz
Lw0KPg0KPiAtICBBZGRlZCBhIHNldCBvZiBGcmVxdWVudGx5IEFza2VkIFF1ZXN0aW9uczogaHR0
cDovL2JpYmZyYW1lLm9yZy9mYXEvDQo+DQo+DQo+DQo+IFdlIGhhdmUgbWFkZSBldmVyeSBlZmZv
cnQgdG8gdXBkYXRlIHRoZSBNQVJDLXRvLUJJQkZSQU1FIHRyYW5zZm9ybWF0aW9uIGNvZGUgYWZ0
ZXIgbW9kaWZ5aW5nIHRoZSB2b2NhYnVsYXJ5LCBhbmQgd2UgcGxhbiB0byBjaGFuZ2UgYW5kIGVu
aGFuY2UgdGhlIGNvZGUgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSB0aGUgcGFwZXJzLiAgWW91IGNh
biBiZWdpbiB1c2luZyB0aGUgdHJhbnNmb3JtYXRpb24gY29kZSB0b2RheSBhcyBhIHJlZmVyZW5j
ZSBhbmQgc3RhcnRpbmcgcG9pbnQgZm9yIHlvdXIgb3duIGV4cGxvcmF0aW9ucy4gIFNlZSB0aGUg
Y29udHJpYnV0ZSBwYWdlIHRvIGxlYXJuIG1vcmU6IGh0dHA6Ly9iaWJmcmFtZS5vcmcvY29udHJp
YnV0ZS8uDQo+DQo+DQo+DQo+IFBsZWFzZSByZWFkIHRoZSBwYXBlcnMgdGhhdCB3ZSBhcmUgYmUg
cHV0dGluZyB1cCBvbiBiaWJmcmFtZS5vcmc8aHR0cDovL2JpYmZyYW1lLm9yZz4gYW5kIHBhcnRp
Y2lwYXRlIGluIHRoZSBkaXNjdXNzaW9uIC0tIHdlIGFyZSBhbGwgaW4gdGhpcyB0b2dldGhlciEN
Cj4NCj4NCj4NCj4gU2FsbHkNCj4NCj4NCj4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioN
Cj4NCj4gU2FsbHkgSC4gTWNDYWxsdW0NCj4NCj4gQ2hpZWYsIE5ldHdvcmsgRGV2ZWxvcG1lbnQg
YW5kIFN0YW5kYXJkcyBPZmZpY2UNCj4NCj4gTGlicmFyeSBvZiBDb25ncmVzcywgIDEwMSBJbmRl
cGVuZGVuY2UgQXZlLiwgU0UNCj4NCj4gV2FzaGluZ3RvbiwgREMgMjA1NDAgIFVTQQ0KPg0KPiBz
bWNjQGxvYy5nb3Y8bWFpbHRvOnNtY2NAbG9jLmdvdj4NCj4NCj4gVGVsLiAxLTIwMi03MDctNTEx
OTx0ZWw6MS0yMDItNzA3LTUxMTk+IC0tIEZheCAxLTIwMi03MDctMDExNTx0ZWw6MS0yMDItNzA3
LTAxMTU+DQo+DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqDQo+DQo+DQoNCg==

--_000_768F135D8DFF3A4A9E4BFF0549723FD953C5211BILEXM02CorpExli_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u
IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC
YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu
LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4w
aW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+
PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9
ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0
PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K
PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBJIHNhaWQgdGhlIGxhc3QgdGlt
ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSAxMDAlIHdpdGggSmVmZi48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNo
bG9tbyBTYW5kZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNUTzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5FeCBMaWJyaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV4cGVyaWVuY2UgdGhlIGFs
bC1uZXcsIHNpbmdpbmcgYW5kIGRhbmNpbmcgaW50ZXJhY3RpdmUNCjxhIGhyZWY9Imh0dHA6Ly93
d3cuZXhsaWJyaXNwdWJsaWNhdGlvbnMuY29tL3ByaW1vLyI+UHJpbW8gYnJvY2h1cmU8L2E+IDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmlibGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJhbnNp
dGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVl0N
CjxiPk9uIEJlaGFsZiBPZiA8L2I+WW91bmcsSmVmZiAoT1IpPGJyPg0KPGI+U2VudDo8L2I+IFN1
bmRheSwgTWF5IDA1LCAyMDEzIDE1OjU5PGJyPg0KPGI+VG86PC9iPiBCSUJGUkFNRUBMSVNUU0VS
Vi5MT0MuR09WPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQklCRlJBTUVdIERvY3VtZW50cyBh
bmQgaW1wcm92ZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCBTS09TIGlzIGFuIGludGVyZXN0aW5nIGlsbHVzdHJh
dGlvbi4gVGhleSBjb3VsZCBoYXZlIHVzZWQgcmVpZmljYXRpb24gb3IgbmFtZWQgZ3JhcGhzIG9y
IGludmVudGVkIHNvbWUgZmxhdm9yIG9mIEFubm90YXRpb24gdG8gc3BlY2lmeSB0aGVpciBzdHJ1
Y3R1cmVzLCBidXQgdGhleSBjaG9zZSB0byBkbyBpdCB3aXRoIHN0cmFpZ2h0IFJERiBpbnN0ZWFk
LiBSYXRoZXIgdGhhbiBhc3N1bWUNCiBSREYgaXNuJ3QgY2FwYWJsZSBvZiB0aGlzIG9yIGRlY2lk
aW5nIGl0cyBub3QgaWRlYWwgaW4gdGhhdCBmb3JtLCB0aGV5IGp1c3QgYml0IHRoZSBidWxsZXQg
YW5kIGRpZCB0aGUgbW9kZWxpbmcgbmVlZGVkIHRvIG1ha2UgaXQgaGFwcGVuLiBJIGxpa2UgdGhh
dCBhYm91dCBTS09TLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5KZWZmPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQYWQ8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PGJyPg0KT24gTWF5IDUsIDIwMTMsIGF0IDY6MTIgQU0sICZxdW90O1NobG9t
byBTYW5kZXJzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86U2hsb21vLlNhbmRlcnNARVhMSUJS
SVNHUk9VUC5DT00iPlNobG9tby5TYW5kZXJzQEVYTElCUklTR1JPVVAuQ09NPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGgg
SmVmZiAxMDAlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbnN0ZWFkIG9mIGNvbnNv
bGlkYXRpbmcgbW9yZSBhbmQgbW9yZSBzdHVmZiBhcmUgZGVmaW5lZC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+QWxsIGZvciBnb29kIHJlYXNvbnMsIGJ1dCB0aGUgYm90dG9tIGxpbmUg
d2lsbCBiZSBsb25nZXIgZm9yIHZlbmRvcnMgdG8gc3VwcG9ydCwgbW9yZSBidWdz4oCmLi48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2hsb21vPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5FeHBlcmllbmNlIHRoZSBhbGwtbmV3LCBzaW5naW5nIGFuZCBkYW5jaW5nIGludGVyYWN0
aXZlDQo8YSBocmVmPSJodHRwOi8vd3d3LmV4bGlicmlzcHVibGljYXRpb25zLmNvbS9wcmltby8i
PlByaW1vIGJyb2NodXJlPC9hPiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+IEJpYmxpb2dyYXBoaWMgRnJhbWV3b3JrIFRyYW5zaXRpb24gSW5pdGlhdGl2ZSBGb3J1
bSBbPGEgaHJlZj0ibWFpbHRvOkJJQkZSQU1FQExJU1RTRVJWLkxPQy5HT1YiPm1haWx0bzpCSUJG
UkFNRUBMSVNUU0VSVi5MT0MuR09WPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFNh
bmRlcnNvbjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1heSAwNSwgMjAxMyAxMTo1MTxicj4N
CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOkJJQkZSQU1FQExJU1RTRVJWLkxPQy5HT1YiPkJJ
QkZSQU1FQExJU1RTRVJWLkxPQy5HT1Y8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQklC
RlJBTUVdIERvY3VtZW50cyBhbmQgaW1wcm92ZW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+U2hsb21vLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5Zb3Ugd2VyZW4ndCBzYXRpc2ZpZWQgd2l0aCB0aGUgZXhwbGFuYXRpb24g
Z2l2ZW4gYXMgdG8gd2h5IHRoaXMgaXMgbm90IHRoZSBjYXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb2I8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiBTdW4sIE1heSA1LCAyMDEzIGF0IDEwOjE4IEFNLCBTaGxvbW8gU2FuZGVycyAm
bHQ7PGEgaHJlZj0ibWFpbHRvOlNobG9tby5TYW5kZXJzQGV4bGlicmlzZ3JvdXAuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+U2hsb21vLlNhbmRlcnNAZXhsaWJyaXNncm91cC5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVhciwgaGVhcjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
U2hsb21vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+RXhwZXJpZW5jZSB0aGUgYWxsLW5ldywgc2luZ2luZyBhbmQg
ZGFuY2luZyBpbnRlcmFjdGl2ZQ0KPGEgaHJlZj0iaHR0cDovL3d3dy5leGxpYnJpc3B1YmxpY2F0
aW9ucy5jb20vcHJpbW8vIiB0YXJnZXQ9Il9ibGFuayI+UHJpbW8gYnJvY2h1cmU8L2E+DQo8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCaWJsaW9ncmFwaGljIEZyYW1ld29yayBUcmFu
c2l0aW9uDQogSW5pdGlhdGl2ZSBGb3J1bSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpCSUJGUkFN
RUBMSVNUU0VSVi5MT0MuR09WIiB0YXJnZXQ9Il9ibGFuayI+QklCRlJBTUVATElTVFNFUlYuTE9D
LkdPVjwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPllvdW5nLEplZmYgKE9SKTxicj4NCjxiPlNl
bnQ6PC9iPiBTYXR1cmRheSwgTWF5IDA0LCAyMDEzIDA2OjI3PGJyPg0KPGI+VG86PC9iPiA8YSBo
cmVmPSJtYWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9DLkdPViIgdGFyZ2V0PSJfYmxhbmsiPkJJ
QkZSQU1FQExJU1RTRVJWLkxPQy5HT1Y8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQklC
RlJBTUVdIERvY3VtZW50cyBhbmQgaW1wcm92ZW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIEthcmVu
IENveWxlIHN1Z2dlc3RlZCAoaWYgSSBza2ltbWVkIGhlciByZWNlbnQgY29tbWVudHMgY29ycmVj
dGx5KSwgd2hhdCBpZiB5b3UgZ3V5cyBjYW4ndCBhZ3JlZSBiZWNhdXNlIHlvdSdyZSBib3RoIG1l
cmVseSByZWludmVudGluZyBSREYgZ3JhcGhzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SmVmZjxicj4NCjxicj4NClNlbnQgZnJvbSBt
eSBpUGFkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
cj4NCk9uIE1heSAzLCAyMDEzLCBhdCA0OjE2IFBNLCAmcXVvdDtSb2JlcnQgU2FuZGVyc29uJnF1
b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YXphcm90aDQyQEdNQUlMLkNPTSIgdGFyZ2V0PSJfYmxh
bmsiPmF6YXJvdGg0MkBHTUFJTC5DT008L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlYXIgU2Fs
bHksIFJheSBhbmQgYWxsLDxicj4NCjxicj4NCkFzIGNvLWNoYWlycyBhbmQgY28tZWRpdG9ycyBv
ZiB0aGUgVzNDIE9wZW4gQW5ub3RhdGlvbiBDb21tdW5pdHkgR3JvdXAsIFBhb2xvLCBIZXJiZXJ0
IGFuZCBJIHdvdWxkIGFnYWluIGxpa2UgdG8gaW52aXRlIG1lbWJlcnMgb2YgdGhlIEJJQkZSQU1F
IGdyb3VwIHRvIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIG9mIGludGVyb3BlcmFibGUgYW5ub3Rh
dGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGZvciB0aGUgVzNDIENvbW11bml0eSBHcm91cC4gVGhl
cmUNCiBpcyBuZWl0aGVyIGEgY29zdCBub3IgbWVtYmVyc2hpcCByZXF1aXJlbWVudCB0byBqb2lu
aW5nLjxicj4NCjxicj4NCldlIGZlZWwgaXQgaXMgZmFpciB0byBzYXkgdGhhdCB0aGUgT3BlbiBB
bm5vdGF0aW9uIGVmZm9ydCBoYXMgZ2FpbmVkIHNpZ25pZmljYW50IG1vbWVudHVtLCBiZWluZyB0
aGUgNnRoIGxhcmdlc3QgY29tbXVuaXR5IGdyb3VwIHdpdGggbWFueSBhY3RpdmUgYW5kIG9uZ29p
bmcgZGlzY3Vzc2lvbnMuIEhvd2V2ZXIgdGhlcmUgaXMgYWx3YXlzIHJvb20gZm9yIGltcHJvdmVt
ZW50LCBhbmQgd2Ugc3RpbGwgYmVsaWV2ZSB0aGF0IGJvdGggQklCRlJBTUUNCiBhbmQgT3BlbiBB
bm5vdGF0aW9uIHdvdWxkIGJlbmVmaXQgZnJvbSBhbiBvcGVuIGRpc2N1c3Npb24gb2YgdGhlIGlz
c3VlcyB0aGF0IHJlc3VsdGVkIGluIHRoZSBkaXZlcmdlbmNlIHdoaWNoIGlzIGNsZWFyIGluIHRo
ZSBhbm5vdGF0aW9uIGRvY3VtZW50Ljxicj4NCjxicj4NCkl0IGlzIHJlZ3JldHRhYmxlIHRoYXQg
dGhlIEJJQkZSQU1FIGFubm90YXRpb24gbW9kZWwgaXMgbmVpdGhlciBjb21wYXRpYmxlIG5vciBp
bnRlcm9wZXJhYmxlIHdpdGggdGhlIE9wZW4gQW5ub3RhdGlvbiBEYXRhIE1vZGVsLCBlc3BlY2lh
bGx5IGdpdmVuIHRoZSBzaWduaWZpY2FudCBvdmVybGFwIGJldHdlZW4gdGhlIHRhcmdldCBjb21t
dW5pdGllcyBvZiBPcGVuIEFubm90YXRpb24gYW5kIEJJQkZSQU1FLiAmbmJzcDtXZSBhcmUgZGlz
YXBwb2ludGVkIHRoYXQNCiBwcmlvciBlZmZvcnRzIHRvIGVuZ2FnZSB3aXRoIHRoZSBCSUJGUkFN
RSBjb21tdW5pdHkgcmVnYXJkaW5nIGFubm90YXRpb24gZGlkIG5vdCB5aWVsZCBtb3JlIGNvbnN0
cnVjdGl2ZSByZXN1bHRzIHRvIHRoaXMgc3RhZ2UuIFdlIGhvcGUgdGhhdCBvdXIgaW52aXRhdGlv
biB0byBkaXNjdXNzIGlzc3VlcyBvbiB0aGUgVzNDIENvbW11bml0eSBHcm91cCB3aWxsIGJlIG1l
dCBwb3NpdGl2ZWx5IGFzIHdlIGZlZWwgd2Ugb3dlIGl0IHRvIG91ciBjb21tdW5pdGllcw0KIHRv
IHdvcmsgdG93YXJkcyBjb252ZXJnZW5jZS48YnI+DQo8YnI+DQpSZXNwZWN0ZnVsbHksPGJyPg0K
PGJyPg0KUm9iZXJ0IFNhbmRlcnNvbiwgUGFvbG8gQ2ljY2FyZXNlLCBhbmQgSGVyYmVydCBWYW4g
ZGUgU29tcGVsPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gRnJpLCBNYXkgMywgMjAxMyBhdCAx
MjowOCBBTSwgTWNDYWxsdW0sIFNhbGx5ICZsdDs8YSBocmVmPSJtYWlsdG86c21jY0Bsb2MuZ292
IiB0YXJnZXQ9Il9ibGFuayI+c21jY0Bsb2MuZ292PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxi
cj4NCiZndDsgVGhhbmtzIHRvIGFsbCBmb3IgeW91ciBjb21tZW50cyBhbmQgaWRlYXMgb3ZlciB0
aGUgbGFzdCBmZXcgbW9udGhzLiAmbmJzcDtUaGUgc21hbGwgdGVhbSB0aGF0IHdlIGhhdmUgY2Fs
bGVkIHRoZSBFYXJseSBFeHBlcmltZW50ZXJzIGhhcyBwcmVwYXJlZCBzb21lIGRpc2N1c3Npb24g
cGFwZXJzIG9uIGRpZmZpY3VsdCB0b3BpY3MgcmVsYXRlZCB0byB0aGUgQklCRlJBTUUgbW9kZWwg
YW5kIHRoZSBkZXZlbG9waW5nIGRyYWZ0IHZvY2FidWxhcnkuICZuYnNwO05vdw0KIHdlIHdhbnQg
dG8gcHV0IHRoZXNlIHBhcGVycyBvbiA8YSBocmVmPSJodHRwOi8vYmliZnJhbWUub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+YmliZnJhbWUub3JnPC9hPiBhbmQgYmVnaW4gZGlzY3Vzc2lvbiBvbiB0aGlz
IGxpc3RzZXJ2LiAmbmJzcDsgQnkgcHJlcGFyaW5nIGJhY2tncm91bmQgYW5kIHJlY29tbWVuZGF0
aW9uIHBhcGVycyB3ZSBob3BlIHRvIGhlbHAgZm9jdXMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGlz
c3Vlcy4NCjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7IFRo
ZSBpc3N1ZXMgYXJlIHNvbWUgb2YgdGhlIGhhcmQgb25lcyB0aGF0IGFsbCBvZiB1cyB3aG8gZGVh
bCB3aXRoIGJpYmxpb2dyYXBoaWMgZGF0YSBydW4gaW50byAmbmJzcDstLSBhbHdheXMuICZuYnNw
OyBXZSBhcmUgc3RhcnRpbmcgd2l0aCB0aGUgQklCRlJBTUUgQW5ub3RhdGlvbnMgcGFwZXIsIHdo
aWNoIHlvdSBjYW4gZmluZCBoZXJlOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDov
L2JpYmZyYW1lLm9yZy9kb2N1bWVudGF0aW9uL2Fubm90YXRpb25zIiB0YXJnZXQ9Il9ibGFuayI+
DQpodHRwOi8vYmliZnJhbWUub3JnL2RvY3VtZW50YXRpb24vYW5ub3RhdGlvbnM8L2E+PGJyPg0K
Jmd0Ozxicj4NCiZndDsgVGhlbiB3ZSBob3BlIHRvIGdldCBkaXNjdXNzaW9uIHBhcGVycyBvbiBC
SUJGUkFNRSBBdXRob3JpdGllcywgUmVsYXRpb25zaGlwcywgPGEgaHJlZj0iaHR0cDovL1NjaGVt
YS5vcmciIHRhcmdldD0iX2JsYW5rIj4NClNjaGVtYS5vcmc8L2E+LCBhbmQgUmVzb3VyY2UgdHlw
ZXMgb3V0IHNvb24sIGZvbGxvd2VkIGJ5IEhvbGRpbmdzLCBBZ2dyZWdhdGVzLCBhbmQgb3RoZXIg
aXNzdWVzLiAmbmJzcDsgVGhlc2Ugd2VyZSBwcmVwYXJlZCBieSB2YXJpb3VzIHN1Ymdyb3VwcyBv
ZiB0aGUgRXhwZXJpbWVudGVyIHRlYW0uICZuYnNwO1dlIGRvIG5vdCB3YW50IHRvIHNlbmQgZXZl
cnl0aGluZyBhdCBvbmNlIGFzIHdlIHdvdWxkIGxpa2UgeW91IHRvIGhhdmUgZm9jdXMgcmF0aGVy
IHRoYW4gb3ZlcmxvYWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4N
CiZndDsgV2UgYXNrIHRoYXQgd2hlbiBkaXNjdXNzaW5nIHRoZSB0b3BpY3MsIHlvdSBuYW1lIHlv
dXIgbGlzdHNlcnYgY29tbWVudCB3aXRoIHRoZSB0b3BpYyBzaG9ydCB0aXRsZSAoaW5kaWNhdGVk
IG9uIHRoZSB0b3BpYyBwYXBlcikgd2l0aCBhbiBleHRyYSB0aXRsZSB0byBiaW5kIHRocmVhZHMs
IGUuZy4sICZxdW90O2Fubm90YXRpb25zLS1tYWluIHBvaW50JnF1b3Q7Ljxicj4NCiZndDs8YnI+
DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGF0IExDIGNvbnRpbnVlIHRvIHdv
cmsgb24gdGhlIGNvbnZlcnNpb24gb2YgTUFSQyBkYXRhLCB3aGljaCwgYWxvbmcgd2l0aCBSREEs
IGlzIHRoZSBjdXJyZW50IGZlZWRlciBvZiB0aGUgY3VycmVudCB2b2NhYnVsYXJ5IGF2YWlsYWJs
ZSBhdA0KPGEgaHJlZj0iaHR0cDovL2JpYmZyYW1lLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRw
Oi8vYmliZnJhbWUub3JnLzwvYT4uICZuYnNwO0luIHRoZSBsYXN0IGNvdXBsZSBvZiBtb250aHMs
IHdlIGhhdmUgbWFkZSB0aGUgZm9sbG93aW5nIGVuaGFuY2VtZW50cyB0byB0aGUgQklCRlJBTUUg
d2Vic2l0ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAt
ICZuYnNwO1JlZ3VsYXJseSB1cGRhdGVkIHRvIHRoZSB2b2NhYnVsYXJ5OiA8YSBocmVmPSJodHRw
Oi8vYmliZnJhbWUub3JnL3ZvY2FiLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2JpYmZyYW1l
Lm9yZy92b2NhYi88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgLSAmbmJzcDtBZGRlZCBCSUJGUkFN
RSBleGFtcGxlIHNuaXBwZXRzIGluIHZvY2FidWxhcnkgc2VjdGlvbjogZS5nLiA8YSBocmVmPSJo
dHRwOi8vYmliZnJhbWUub3JnL3ZvY2FiL2NsYXNzLWxjYyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0
cDovL2JpYmZyYW1lLm9yZy92b2NhYi9jbGFzcy1sY2M8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsg
LSAmbmJzcDtJbXByb3ZlZCB0aGUgTUFSQy10by1CSUJGUkFNRSBjb2RlOiA8YSBocmVmPSJodHRw
Oi8vYmliZnJhbWUub3JnL3Rvb2xzLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2JpYmZyYW1l
Lm9yZy90b29scy88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgLSAmbmJzcDtBZGRlZCBhIHNldCBv
ZiBGcmVxdWVudGx5IEFza2VkIFF1ZXN0aW9uczogPGEgaHJlZj0iaHR0cDovL2JpYmZyYW1lLm9y
Zy9mYXEvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vYmliZnJhbWUub3JnL2ZhcS88L2E+PGJy
Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4NCiZndDsgV2UgaGF2ZSBtYWRl
IGV2ZXJ5IGVmZm9ydCB0byB1cGRhdGUgdGhlIE1BUkMtdG8tQklCRlJBTUUgdHJhbnNmb3JtYXRp
b24gY29kZSBhZnRlciBtb2RpZnlpbmcgdGhlIHZvY2FidWxhcnksIGFuZCB3ZSBwbGFuIHRvIGNo
YW5nZSBhbmQgZW5oYW5jZSB0aGUgY29kZSBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIHRoZSBwYXBl
cnMuICZuYnNwO1lvdSBjYW4gYmVnaW4gdXNpbmcgdGhlIHRyYW5zZm9ybWF0aW9uIGNvZGUgdG9k
YXkgYXMgYSByZWZlcmVuY2UgYW5kDQogc3RhcnRpbmcgcG9pbnQgZm9yIHlvdXIgb3duIGV4cGxv
cmF0aW9ucy4gJm5ic3A7U2VlIHRoZSBjb250cmlidXRlIHBhZ2UgdG8gbGVhcm4gbW9yZToNCjxh
IGhyZWY9Imh0dHA6Ly9iaWJmcmFtZS5vcmcvY29udHJpYnV0ZS8iIHRhcmdldD0iX2JsYW5rIj5o
dHRwOi8vYmliZnJhbWUub3JnL2NvbnRyaWJ1dGUvPC9hPi48YnI+DQomZ3Q7PGJyPg0KJmd0OyAm
bmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2UgcmVhZCB0aGUgcGFwZXJzIHRoYXQgd2Ug
YXJlIGJlIHB1dHRpbmcgdXAgb24gPGEgaHJlZj0iaHR0cDovL2JpYmZyYW1lLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPg0KYmliZnJhbWUub3JnPC9hPiBhbmQgcGFydGljaXBhdGUgaW4gdGhlIGRpc2N1
c3Npb24gLS0gd2UgYXJlIGFsbCBpbiB0aGlzIHRvZ2V0aGVyITxicj4NCiZndDs8YnI+DQomZ3Q7
ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7IFNhbGx5PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5i
c3A7PGJyPg0KJmd0Ozxicj4NCiZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQom
Z3Q7PGJyPg0KJmd0OyBTYWxseSBILiBNY0NhbGx1bTxicj4NCiZndDs8YnI+DQomZ3Q7IENoaWVm
LCBOZXR3b3JrIERldmVsb3BtZW50IGFuZCBTdGFuZGFyZHMgT2ZmaWNlPGJyPg0KJmd0Ozxicj4N
CiZndDsgTGlicmFyeSBvZiBDb25ncmVzcywgJm5ic3A7MTAxIEluZGVwZW5kZW5jZSBBdmUuLCBT
RTxicj4NCiZndDs8YnI+DQomZ3Q7IFdhc2hpbmd0b24sIERDIDIwNTQwICZuYnNwO1VTQTxicj4N
CiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpzbWNjQGxvYy5nb3YiIHRhcmdldD0iX2Js
YW5rIj5zbWNjQGxvYy5nb3Y8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGVsLiA8YSBocmVmPSJ0
ZWw6MS0yMDItNzA3LTUxMTkiIHRhcmdldD0iX2JsYW5rIj4xLTIwMi03MDctNTExOTwvYT4gLS0g
RmF4IDxhIGhyZWY9InRlbDoxLTIwMi03MDctMDExNSIgdGFyZ2V0PSJfYmxhbmsiPg0KMS0yMDIt
NzA3LTAxMTU8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgKioqKioqKioqKioqKioqKioqKioqKioq
Kio8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_768F135D8DFF3A4A9E4BFF0549723FD953C5211BILEXM02CorpExli_--

------------------------------

Date:    Sun, 5 May 2013 08:02:17 -0700
From:    Karen Coyle <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

This is a multi-part message in MIME format.
--------------050900000904010406030208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rob - thanks for your comments, and just a few more of mine. I'll try to 
reduce things down a bit.

First, it has occurred to me that, perhaps ironically, the "Functional 
Requirements for Authority Data", FRAD, [1] is very close to OA. 
Unfortunately, the English version isn't available online, but if you 
grab one of the ones whose language you can make out, all that really 
matters is Figure 2 (p. 7 in the French version, for example). It's not 
exactly the same, but I sense a similarity in the intent, especially in 
terms of making clear WHO is making the statement. FRAD adds one more 
thing, which is under which rules the statement is being made. I could 
imagine, therefore, BIBFRAME authorities looking much like OA if FRAD is 
adopted.


On 5/5/13 2:17 AM, Robert Sanderson wrote:
>
> Agreed, however these were simply to demonstrate that annotations 
> expressed in RDF require more than a single reified triple, to refute 
> the claim that we're simply reinventing RDF graphs.  There needs to be 
> an ontology and defined structure.

Yes, and this is bringing up for me some work I'm doing around the 
Dublin Core Application Profiles [2]. I need to catch some other folks 
to have a discussion of this, but will get back to you if anything 
interesting arises.
> Yes, definitely.  The cataloguing type of use cases I would see as 
> clearly annotations:
>
> * Reviews / Notes
> * Tagging / Subject classification
> * Citations
>
> Essentially, when the information is provided by a third party, then 
> it would be good to be expressed as an Annotation such that the 
> provenance information is maintained and is compatible with other 
> systems that use Open Annotation.

I'm still having a hard time with the dividing line between stuff and 
annotations of stuff. A recent article explaining the OA concept [3] said:

  "Annotations describe resources with additional information, which is 
valu-
     able to other users, who are searching and browsing resource 
collections."

If you have "additional information" then there must be "non-additional 
information" -- and if you have a third party then there must be a first 
party (the second seems to get skipped over in that analogy). I don't 
think this is a generalizable question (one person's "additional"... 
etc.), but at least for any community like libraries some definition is 
going to be needed if annotations will have some operational meaning. 
That's what I think is not clear (yet) in the BIBFRAME document. I 
suspect that the division in library data will be based on provenance, 
but that's not how BIBFRAME defines annotation.

>
>
> The point I was trying to make is that the bibframe annotation model 
> has a property bf:annotationBodyLiteral, which has a literal as the 
> object.  The Open Annotation model explicitly does not allow this, for 
> several important and well discussed reasons.  Thus a point where the 
> two models are not compatible.

Right. But then again, DC types doesn't include "literal" as a type. The 
whole typing thing is something I would need to think about more. If 
your only interest is literal v. URI, then the BIBFRAME choice is fine. 
If you have a video or sound file, that would be a URI. Something that 
is interesting in the OA model is that it allows you to make statements 
about the thing the URI points to [e.g. annotating a particular 
coordinate area on a map]. I hadn't thought about that, and now will 
have to go back to the OA document and see where that fits in. This is 
one of those areas where the "meta" aspect of library data has an 
affect. Must think more.....

>
>
>     Note that there is nothing about library data that would prevent
>     anyone from applying an Open Annotation to the data. The question
>     is, do we want this to be the only way to, for example, assign a
>     subject heading to a Work? OrI wouldn't assume that the BIBFRAME
>     data will exist *as is* in the open world.
>
>
> Then I would seriously question why RDF is being used at all.

I see this differently, perhaps because of my work on Application 
Profiles. I think that many communities will have an internal view of 
their data, and another "face" that they present to the open world. The 
basic structure of RDF, that is, triples, and the use of defined 
ontologies, is a good way to organize data whether it is open or not. In 
fact, there are enterprise uses of linked data. Modeling your enterprise 
data on RDF makes it much more likely that you will be able to extract a 
public view. In the Dublin Core arena we are looking at Application 
Profiles as a way to add the constraints that are needed within a 
community or enterprise that has some non-open needs, while easily 
allowing the derivation of an open view.

> Was the choice of annotation as a model discussed on this list (and 
> hence available in the archives) or was it simply presented fait accompli?

Rob, what you and I are doing here is the full extent of our ability to 
interact in the BIBFRAME process. If you look at the "Contribute" page 
[4] of BIBFRAME you will see that the only involvement for the community 
in the BIBFRAME development is discussion on this list. Discussion that, 
like this thread, takes place generally between list members with no 
direct involvement in BIBFRAME development. I would have simply replied 
to you individually, but I'm of the mind that a few readers on the list 
might find our musings interesting. In terms of having any influence 
over the development of BIBFRAME, I have no such conceit.

kc

[1] 
http://www.ifla.org/publications/functional-requirements-for-authority-data
[2] http://dublincore.org/documents/dc-dsp/
[3] 
http://www.springer.com/computer/information+systems+and+applications/journal/11042
[4] http://bibframe.org/contribute/

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet


--------------050900000904010406030208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Rob - thanks for your comments, and just a few more of mine. I'll
    try to reduce things down a bit.<br>
    <br>
    First, it has occurred to me that, perhaps ironically, the
    "Functional Requirements for Authority Data", FRAD, [1] is very
    close to OA. Unfortunately, the English version isn't available
    online, but if you grab one of the ones whose language you can make
    out, all that really matters is Figure 2 (p. 7 in the French
    version, for example). It's not exactly the same, but I sense a
    similarity in the intent, especially in terms of making clear WHO is
    making the statement. FRAD adds one more thing, which is under which
    rules the statement is being made. I could imagine, therefore,
    BIBFRAME authorities looking much like OA if FRAD is adopted.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/5/13 2:17 AM, Robert Sanderson
      wrote:<br>
    </div>
    <blockquote
cite="mid:[log in to unmask]"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div style="">Agreed, however these were simply to
              demonstrate that annotations expressed in RDF require more
              than a single reified triple, to refute the claim that
              we're simply reinventing RDF graphs. &nbsp;There needs to be an
              ontology and defined structure.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, and this is bringing up for me some work I'm doing around the
    Dublin Core Application Profiles [2]. I need to catch some other
    folks to have a discussion of this, but will get back to you if
    anything interesting arises.
    <blockquote
cite="mid:[log in to unmask]"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
              <div>Yes, definitely. &nbsp;The cataloguing type of use cases I
                would see as clearly annotations:</div>
              <div><br>
              </div>
              <div>* Reviews / Notes</div>
              <div>* Tagging / Subject classification<br>
              </div>
              <div>* Citations</div>
            </div>
            <div><br>
            </div>
            <div style="">Essentially, when the information is provided
              by a third party, then it would be good to be expressed as
              an Annotation such that the provenance information is
              maintained and is compatible with other systems that use
              Open Annotation.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I'm still having a hard time with the dividing line between stuff
    and annotations of stuff. A recent article explaining the OA concept
    [3] said:<br>
    <br>
    &nbsp;"Annotations describe resources with additional information, which
    is valu-<br>
    &nbsp;&nbsp;&nbsp; able to other users, who are searching and browsing resource
    collections."<br>
    <br>
    If you have "additional information" then there must be
    "non-additional information" -- and if you have a third party then
    there must be a first party (the second seems to get skipped over in
    that analogy). I don't think this is a generalizable question (one
    person's "additional"... etc.), but at least for any community like
    libraries some definition is going to be needed if annotations will
    have some operational meaning. That's what I think is not clear
    (yet) in the BIBFRAME document. I suspect that the division in
    library data will be based on provenance, but that's not how
    BIBFRAME defines annotation.<br>
    <br>
    <blockquote
cite="mid:[log in to unmask]"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div><br>
            </div>
            <div style="">The point I was trying to make is that the
              bibframe annotation model has a property
              bf:annotationBodyLiteral, which has a literal as the
              object. &nbsp;The Open Annotation model explicitly does not
              allow this, for several important and well discussed
              reasons. &nbsp;Thus a point where the two models are not
              compatible.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Right. But then again, DC types doesn't include "literal" as a type.
    The whole typing thing is something I would need to think about
    more. If your only interest is literal v. URI, then the BIBFRAME
    choice is fine. If you have a video or sound file, that would be a
    URI. Something that is interesting in the OA model is that it allows
    you to make statements about the thing the URI points to [e.g.
    annotating a particular coordinate area on a map]. I hadn't thought
    about that, and now will have to go back to the OA document and see
    where that fits in. This is one of those areas where the "meta"
    aspect of library data has an affect. Must think more.....<br>
    <br>
    <blockquote
cite="mid:[log in to unmask]"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                Note that there is nothing about library data that would
                prevent anyone from applying an Open Annotation to the
                data. The question is, do we want this to be the only
                way to, for example, assign a subject heading to a Work?
                OrI wouldn't assume that the BIBFRAME data will exist
                *as is* in the open world. </div>
            </blockquote>
            <div><br>
            </div>
            <div style="">Then I would seriously question why RDF is
              being used at all.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I see this differently, perhaps because of my work on Application
    Profiles. I think that many communities will have an internal view
    of their data, and another "face" that they present to the open
    world. The basic structure of RDF, that is, triples, and the use of
    defined ontologies, is a good way to organize data whether it is
    open or not. In fact, there are enterprise uses of linked data.
    Modeling your enterprise data on RDF makes it much more likely that
    you will be able to extract a public view. In the Dublin Core arena
    we are looking at Application Profiles as a way to add the
    constraints that are needed within a community or enterprise that
    has some non-open needs, while easily allowing the derivation of an
    open view.<br>
    <br>
    <blockquote
cite="mid:[log in to unmask]"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</div>
            <div style="">Was the choice of annotation as a model
              discussed on this list (and hence available in the
              archives) or was it simply presented fait accompli?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Rob, what you and I are doing here is the full extent of our ability
    to interact in the BIBFRAME process. If you look at the "Contribute"
    page [4] of BIBFRAME you will see that the only involvement for the
    community in the BIBFRAME development is discussion on this list.
    Discussion that, like this thread, takes place generally between
    list members with no direct involvement in BIBFRAME development. I
    would have simply replied to you individually, but I'm of the mind
    that a few readers on the list might find our musings interesting.
    In terms of having any influence over the development of BIBFRAME, I
    have no such conceit.<br>
    <br>
    kc<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="http://www.ifla.org/publications/functional-requirements-for-authority-data">http://www.ifla.org/publications/functional-requirements-for-authority-data</a><br>
    [2] <a class="moz-txt-link-freetext" href="http://dublincore.org/documents/dc-dsp/">http://dublincore.org/documents/dc-dsp/</a><br>
    [3]
<a class="moz-txt-link-freetext" href="http://www.springer.com/computer/information+systems+and+applications/journal/11042">http://www.springer.com/computer/information+systems+and+applications/journal/11042</a><br>
    [4] <a class="moz-txt-link-freetext" href="http://bibframe.org/contribute/">http://bibframe.org/contribute/</a><br>
    <pre class="moz-signature" cols="72">-- 
Karen Coyle
<a class="moz-txt-link-abbreviated" href="mailto:[log in to unmask]">[log in to unmask]</a> <a class="moz-txt-link-freetext" href="http://kcoyle.net">http://kcoyle.net</a>
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet</pre>
  </body>
</html>

--------------050900000904010406030208--

------------------------------

Date:    Sun, 5 May 2013 11:05:58 -0400
From:    "Young,Jeff (OR)" <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

--Apple-Mail-C62FE8EC-E45F-4806-BCA7-8740BE44EE33
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Or SKOS for that matter...

Sent from my iPad

On May 5, 2013, at 11:03 AM, "Karen Coyle" <[log in to unmask]> wrote:

> Rob - thanks for your comments, and just a few more of mine. I'll try to r=
educe things down a bit.
>=20
> First, it has occurred to me that, perhaps ironically, the "Functional Req=
uirements for Authority Data", FRAD, [1] is very close to OA. Unfortunately,=
 the English version isn't available online, but if you grab one of the ones=
 whose language you can make out, all that really matters is Figure 2 (p. 7 i=
n the French version, for example). It's not exactly the same, but I sense a=
 similarity in the intent, especially in terms of making clear WHO is making=
 the statement. FRAD adds one more thing, which is under which rules the sta=
tement is being made. I could imagine, therefore, BIBFRAME authorities looki=
ng much like OA if FRAD is adopted.
>=20
>=20
> On 5/5/13 2:17 AM, Robert Sanderson wrote:
>>=20
>> Agreed, however these were simply to demonstrate that annotations express=
ed in RDF require more than a single reified triple, to refute the claim tha=
t we're simply reinventing RDF graphs.  There needs to be an ontology and de=
fined structure.
>=20
> Yes, and this is bringing up for me some work I'm doing around the Dublin C=
ore Application Profiles [2]. I need to catch some other folks to have a dis=
cussion of this, but will get back to you if anything interesting arises.
>>=20
>> Yes, definitely.  The cataloguing type of use cases I would see as clearl=
y annotations:
>>=20
>> * Reviews / Notes
>> * Tagging / Subject classification
>> * Citations
>>=20
>> Essentially, when the information is provided by a third party, then it w=
ould be good to be expressed as an Annotation such that the provenance infor=
mation is maintained and is compatible with other systems that use Open Anno=
tation.
>=20
> I'm still having a hard time with the dividing line between stuff and anno=
tations of stuff. A recent article explaining the OA concept [3] said:
>=20
>  "Annotations describe resources with additional information, which is val=
u-
>     able to other users, who are searching and browsing resource collectio=
ns."
>=20
> If you have "additional information" then there must be "non-additional in=
formation" -- and if you have a third party then there must be a first party=
 (the second seems to get skipped over in that analogy). I don't think this i=
s a generalizable question (one person's "additional"... etc.), but at least=
 for any community like libraries some definition is going to be needed if a=
nnotations will have some operational meaning. That's what I think is not cl=
ear (yet) in the BIBFRAME document. I suspect that the division in library d=
ata will be based on provenance, but that's not how BIBFRAME defines annotat=
ion.
>=20
>>=20
>>=20
>> The point I was trying to make is that the bibframe annotation model has a=
 property bf:annotationBodyLiteral, which has a literal as the object.  The O=
pen Annotation model explicitly does not allow this, for several important a=
nd well discussed reasons.  Thus a point where the two models are not compat=
ible.
>=20
> Right. But then again, DC types doesn't include "literal" as a type. The w=
hole typing thing is something I would need to think about more. If your onl=
y interest is literal v. URI, then the BIBFRAME choice is fine. If you have a=
 video or sound file, that would be a URI. Something that is interesting in t=
he OA model is that it allows you to make statements about the thing the URI=
 points to [e.g. annotating a particular coordinate area on a map]. I hadn't=
 thought about that, and now will have to go back to the OA document and see=
 where that fits in. This is one of those areas where the "meta" aspect of l=
ibrary data has an affect. Must think more.....
>=20
>>=20
>>=20
>>> Note that there is nothing about library data that would prevent anyone f=
rom applying an Open Annotation to the data. The question is, do we want thi=
s to be the only way to, for example, assign a subject heading to a Work? Or=
I wouldn't assume that the BIBFRAME data will exist *as is* in the open worl=
d.
>>=20
>> Then I would seriously question why RDF is being used at all.
>=20
> I see this differently, perhaps because of my work on Application Profiles=
. I think that many communities will have an internal view of their data, an=
d another "face" that they present to the open world. The basic structure of=
 RDF, that is, triples, and the use of defined ontologies, is a good way to o=
rganize data whether it is open or not. In fact, there are enterprise uses o=
f linked data. Modeling your enterprise data on RDF makes it much more likel=
y that you will be able to extract a public view. In the Dublin Core arena w=
e are looking at Application Profiles as a way to add the constraints that a=
re needed within a community or enterprise that has some non-open needs, whi=
le easily allowing the derivation of an open view.
>=20
>> =20
>> Was the choice of annotation as a model discussed on this list (and hence=
 available in the archives) or was it simply presented fait accompli?
>=20
> Rob, what you and I are doing here is the full extent of our ability to in=
teract in the BIBFRAME process. If you look at the "Contribute" page [4] of B=
IBFRAME you will see that the only involvement for the community in the BIBFR=
AME development is discussion on this list. Discussion that, like this threa=
d, takes place generally between list members with no direct involvement in B=
IBFRAME development. I would have simply replied to you individually, but I'=
m of the mind that a few readers on the list might find our musings interest=
ing. In terms of having any influence over the development of BIBFRAME, I ha=
ve no such conceit.
>=20
> kc
>=20
> [1] http://www.ifla.org/publications/functional-requirements-for-authority=
-data
> [2] http://dublincore.org/documents/dc-dsp/
> [3] http://www.springer.com/computer/information+systems+and+applications/=
journal/11042
> [4] http://bibframe.org/contribute/
> --=20
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

--Apple-Mail-C62FE8EC-E45F-4806-BCA7-8740BE44EE33
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Or SKOS for that matter...<br><br>Sent from my iPad</div><div><br>On May 5, 2013, at 11:03 AM, "Karen Coyle" &lt;<a href="mailto:[log in to unmask]">[log in to unmask]</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  
    Rob - thanks for your comments, and just a few more of mine. I'll
    try to reduce things down a bit.<br>
    <br>
    First, it has occurred to me that, perhaps ironically, the
    "Functional Requirements for Authority Data", FRAD, [1] is very
    close to OA. Unfortunately, the English version isn't available
    online, but if you grab one of the ones whose language you can make
    out, all that really matters is Figure 2 (p. 7 in the French
    version, for example). It's not exactly the same, but I sense a
    similarity in the intent, especially in terms of making clear WHO is
    making the statement. FRAD adds one more thing, which is under which
    rules the statement is being made. I could imagine, therefore,
    BIBFRAME authorities looking much like OA if FRAD is adopted.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/5/13 2:17 AM, Robert Sanderson
      wrote:<br>
    </div>
    <blockquote cite="mid:[log in to unmask]" type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div style="">Agreed, however these were simply to
              demonstrate that annotations expressed in RDF require more
              than a single reified triple, to refute the claim that
              we're simply reinventing RDF graphs. &nbsp;There needs to be an
              ontology and defined structure.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, and this is bringing up for me some work I'm doing around the
    Dublin Core Application Profiles [2]. I need to catch some other
    folks to have a discussion of this, but will get back to you if
    anything interesting arises.
    <blockquote cite="mid:[log in to unmask]" type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
              <div>Yes, definitely. &nbsp;The cataloguing type of use cases I
                would see as clearly annotations:</div>
              <div><br>
              </div>
              <div>* Reviews / Notes</div>
              <div>* Tagging / Subject classification<br>
              </div>
              <div>* Citations</div>
            </div>
            <div><br>
            </div>
            <div style="">Essentially, when the information is provided
              by a third party, then it would be good to be expressed as
              an Annotation such that the provenance information is
              maintained and is compatible with other systems that use
              Open Annotation.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I'm still having a hard time with the dividing line between stuff
    and annotations of stuff. A recent article explaining the OA concept
    [3] said:<br>
    <br>
    &nbsp;"Annotations describe resources with additional information, which
    is valu-<br>
    &nbsp;&nbsp;&nbsp; able to other users, who are searching and browsing resource
    collections."<br>
    <br>
    If you have "additional information" then there must be
    "non-additional information" -- and if you have a third party then
    there must be a first party (the second seems to get skipped over in
    that analogy). I don't think this is a generalizable question (one
    person's "additional"... etc.), but at least for any community like
    libraries some definition is going to be needed if annotations will
    have some operational meaning. That's what I think is not clear
    (yet) in the BIBFRAME document. I suspect that the division in
    library data will be based on provenance, but that's not how
    BIBFRAME defines annotation.<br>
    <br>
    <blockquote cite="mid:[log in to unmask]" type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div><br>
            </div>
            <div style="">The point I was trying to make is that the
              bibframe annotation model has a property
              bf:annotationBodyLiteral, which has a literal as the
              object. &nbsp;The Open Annotation model explicitly does not
              allow this, for several important and well discussed
              reasons. &nbsp;Thus a point where the two models are not
              compatible.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Right. But then again, DC types doesn't include "literal" as a type.
    The whole typing thing is something I would need to think about
    more. If your only interest is literal v. URI, then the BIBFRAME
    choice is fine. If you have a video or sound file, that would be a
    URI. Something that is interesting in the OA model is that it allows
    you to make statements about the thing the URI points to [e.g.
    annotating a particular coordinate area on a map]. I hadn't thought
    about that, and now will have to go back to the OA document and see
    where that fits in. This is one of those areas where the "meta"
    aspect of library data has an affect. Must think more.....<br>
    <br>
    <blockquote cite="mid:[log in to unmask]" type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                Note that there is nothing about library data that would
                prevent anyone from applying an Open Annotation to the
                data. The question is, do we want this to be the only
                way to, for example, assign a subject heading to a Work?
                OrI wouldn't assume that the BIBFRAME data will exist
                *as is* in the open world. </div>
            </blockquote>
            <div><br>
            </div>
            <div style="">Then I would seriously question why RDF is
              being used at all.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I see this differently, perhaps because of my work on Application
    Profiles. I think that many communities will have an internal view
    of their data, and another "face" that they present to the open
    world. The basic structure of RDF, that is, triples, and the use of
    defined ontologies, is a good way to organize data whether it is
    open or not. In fact, there are enterprise uses of linked data.
    Modeling your enterprise data on RDF makes it much more likely that
    you will be able to extract a public view. In the Dublin Core arena
    we are looking at Application Profiles as a way to add the
    constraints that are needed within a community or enterprise that
    has some non-open needs, while easily allowing the derivation of an
    open view.<br>
    <br>
    <blockquote cite="mid:[log in to unmask]" type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>&nbsp;</div>
            <div style="">Was the choice of annotation as a model
              discussed on this list (and hence available in the
              archives) or was it simply presented fait accompli?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Rob, what you and I are doing here is the full extent of our ability
    to interact in the BIBFRAME process. If you look at the "Contribute"
    page [4] of BIBFRAME you will see that the only involvement for the
    community in the BIBFRAME development is discussion on this list.
    Discussion that, like this thread, takes place generally between
    list members with no direct involvement in BIBFRAME development. I
    would have simply replied to you individually, but I'm of the mind
    that a few readers on the list might find our musings interesting.
    In terms of having any influence over the development of BIBFRAME, I
    have no such conceit.<br>
    <br>
    kc<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="http://www.ifla.org/publications/functional-requirements-for-authority-data">http://www.ifla.org/publications/functional-requirements-for-authority-data</a><br>
    [2] <a class="moz-txt-link-freetext" href="http://dublincore.org/documents/dc-dsp/">http://dublincore.org/documents/dc-dsp/</a><br>
    [3]
<a class="moz-txt-link-freetext" href="http://www.springer.com/computer/information+systems+and+applications/journal/11042">http://www.springer.com/computer/information+systems+and+applications/journal/11042</a><br>
    [4] <a class="moz-txt-link-freetext" href="http://bibframe.org/contribute/">http://bibframe.org/contribute/</a><br>
    <pre class="moz-signature" cols="72">-- 
Karen Coyle
<a class="moz-txt-link-abbreviated" href="mailto:[log in to unmask]">[log in to unmask]</a> <a class="moz-txt-link-freetext" href="http://kcoyle.net">http://kcoyle.net</a>
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet</pre>
  

</div></blockquote></body></html>
--Apple-Mail-C62FE8EC-E45F-4806-BCA7-8740BE44EE33--

------------------------------

Date:    Sun, 5 May 2013 08:26:23 -0700
From:    Karen Coyle <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

This is a multi-part message in MIME format.
--------------040000020202030108050901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Jeff, I'm thinking about the part of FRAD that is outside of the main 
box (which I think may be handled by SKOS). There are some structures 
that modify (or, annotate) the authority data:

First, there is a "box" with:
  - name
  - identifier

Both of these are SKOS-able, I believe.

That "box" itself is modified with:
   - Access point
   -- Rules (for access point)
   --- Agency (that applied the rules)

It is this last part that looks OA-ish to me. This goes beyond what you 
have in VIAF, which contains an identifier for the original source, but 
doesn't separate access points from identities (as far as I can tell), 
and doesn't include rules. The Agency covered by the source URI is 
implied, but if you have something like NACO you may want the actual 
agency that made the decision (040 $a or something like that).

kc



On 5/5/13 8:05 AM, Young,Jeff (OR) wrote:
> Or SKOS for that matter...
>
> Sent from my iPad
>
> On May 5, 2013, at 11:03 AM, "Karen Coyle" <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>> Rob - thanks for your comments, and just a few more of mine. I'll try 
>> to reduce things down a bit.
>>
>> First, it has occurred to me that, perhaps ironically, the 
>> "Functional Requirements for Authority Data", FRAD, [1] is very close 
>> to OA. Unfortunately, the English version isn't available online, but 
>> if you grab one of the ones whose language you can make out, all that 
>> really matters is Figure 2 (p. 7 in the French version, for example). 
>> It's not exactly the same, but I sense a similarity in the intent, 
>> especially in terms of making clear WHO is making the statement. FRAD 
>> adds one more thing, which is under which rules the statement is 
>> being made. I could imagine, therefore, BIBFRAME authorities looking 
>> much like OA if FRAD is adopted.
>>
>>
>> On 5/5/13 2:17 AM, Robert Sanderson wrote:
>>>
>>> Agreed, however these were simply to demonstrate that annotations 
>>> expressed in RDF require more than a single reified triple, to 
>>> refute the claim that we're simply reinventing RDF graphs.  There 
>>> needs to be an ontology and defined structure.
>>
>> Yes, and this is bringing up for me some work I'm doing around the 
>> Dublin Core Application Profiles [2]. I need to catch some other 
>> folks to have a discussion of this, but will get back to you if 
>> anything interesting arises.
>>> Yes, definitely.  The cataloguing type of use cases I would see as 
>>> clearly annotations:
>>>
>>> * Reviews / Notes
>>> * Tagging / Subject classification
>>> * Citations
>>>
>>> Essentially, when the information is provided by a third party, then 
>>> it would be good to be expressed as an Annotation such that the 
>>> provenance information is maintained and is compatible with other 
>>> systems that use Open Annotation.
>>
>> I'm still having a hard time with the dividing line between stuff and 
>> annotations of stuff. A recent article explaining the OA concept [3] 
>> said:
>>
>>  "Annotations describe resources with additional information, which 
>> is valu-
>>     able to other users, who are searching and browsing resource 
>> collections."
>>
>> If you have "additional information" then there must be 
>> "non-additional information" -- and if you have a third party then 
>> there must be a first party (the second seems to get skipped over in 
>> that analogy). I don't think this is a generalizable question (one 
>> person's "additional"... etc.), but at least for any community like 
>> libraries some definition is going to be needed if annotations will 
>> have some operational meaning. That's what I think is not clear (yet) 
>> in the BIBFRAME document. I suspect that the division in library data 
>> will be based on provenance, but that's not how BIBFRAME defines 
>> annotation.
>>
>>>
>>>
>>> The point I was trying to make is that the bibframe annotation model 
>>> has a property bf:annotationBodyLiteral, which has a literal as the 
>>> object.  The Open Annotation model explicitly does not allow this, 
>>> for several important and well discussed reasons.  Thus a point 
>>> where the two models are not compatible.
>>
>> Right. But then again, DC types doesn't include "literal" as a type. 
>> The whole typing thing is something I would need to think about more. 
>> If your only interest is literal v. URI, then the BIBFRAME choice is 
>> fine. If you have a video or sound file, that would be a URI. 
>> Something that is interesting in the OA model is that it allows you 
>> to make statements about the thing the URI points to [e.g. annotating 
>> a particular coordinate area on a map]. I hadn't thought about that, 
>> and now will have to go back to the OA document and see where that 
>> fits in. This is one of those areas where the "meta" aspect of 
>> library data has an affect. Must think more.....
>>
>>>
>>>
>>>     Note that there is nothing about library data that would prevent
>>>     anyone from applying an Open Annotation to the data. The
>>>     question is, do we want this to be the only way to, for example,
>>>     assign a subject heading to a Work? OrI wouldn't assume that the
>>>     BIBFRAME data will exist *as is* in the open world.
>>>
>>>
>>> Then I would seriously question why RDF is being used at all.
>>
>> I see this differently, perhaps because of my work on Application 
>> Profiles. I think that many communities will have an internal view of 
>> their data, and another "face" that they present to the open world. 
>> The basic structure of RDF, that is, triples, and the use of defined 
>> ontologies, is a good way to organize data whether it is open or not. 
>> In fact, there are enterprise uses of linked data. Modeling your 
>> enterprise data on RDF makes it much more likely that you will be 
>> able to extract a public view. In the Dublin Core arena we are 
>> looking at Application Profiles as a way to add the constraints that 
>> are needed within a community or enterprise that has some non-open 
>> needs, while easily allowing the derivation of an open view.
>>
>>> Was the choice of annotation as a model discussed on this list (and 
>>> hence available in the archives) or was it simply presented fait 
>>> accompli?
>>
>> Rob, what you and I are doing here is the full extent of our ability 
>> to interact in the BIBFRAME process. If you look at the "Contribute" 
>> page [4] of BIBFRAME you will see that the only involvement for the 
>> community in the BIBFRAME development is discussion on this list. 
>> Discussion that, like this thread, takes place generally between list 
>> members with no direct involvement in BIBFRAME development. I would 
>> have simply replied to you individually, but I'm of the mind that a 
>> few readers on the list might find our musings interesting. In terms 
>> of having any influence over the development of BIBFRAME, I have no 
>> such conceit.
>>
>> kc
>>
>> [1] 
>> http://www.ifla.org/publications/functional-requirements-for-authority-data
>> [2] http://dublincore.org/documents/dc-dsp/
>> [3] 
>> http://www.springer.com/computer/information+systems+and+applications/journal/11042
>> [4] http://bibframe.org/contribute/
>> -- 
>> Karen Coyle
>> [log in to unmask]  http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet


--------------040000020202030108050901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Jeff, I'm thinking about the part of FRAD that is outside of the
    main box (which I think may be handled by SKOS). There are some
    structures that modify (or, annotate) the authority data:<br>
    <br>
    First, there is a "box" with:<br>
    Â - name<br>
    Â - identifier<br>
    <br>
    Both of these are SKOS-able, I believe.<br>
    <br>
    That "box" itself is modified with:<br>
    Â  - Access point<br>
    Â  -- Rules (for access point)<br>
    Â  --- Agency (that applied the rules)<br>
    <br>
    It is this last part that looks OA-ish to me. This goes beyond what
    you have in VIAF, which contains an identifier for the original
    source, but doesn't separate access points from identities (as far
    as I can tell), and doesn't include rules. The Agency covered by the
    source URI is implied, but if you have something like NACO you may
    want the actual agency that made the decision (040 $a or something
    like that).<br>
    <br>
    kc<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/5/13 8:05 AM, Young,Jeff (OR)
      wrote:<br>
    </div>
    <blockquote cite="mid:[log in to unmask]"
      type="cite">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div>Or SKOS for that matter...<br>
        <br>
        Sent from my iPad</div>
      <div><br>
        On May 5, 2013, at 11:03 AM, "Karen Coyle" &lt;<a
          moz-do-not-send="true" href="mailto:[log in to unmask]">[log in to unmask]</a>&gt;
        wrote:<br>
        <br>
      </div>
      <blockquote type="cite">
        <div>
          <meta content="text/html; charset=UTF-8"
            http-equiv="Content-Type">
          Rob - thanks for your comments, and just a few more of mine.
          I'll try to reduce things down a bit.<br>
          <br>
          First, it has occurred to me that, perhaps ironically, the
          "Functional Requirements for Authority Data", FRAD, [1] is
          very close to OA. Unfortunately, the English version isn't
          available online, but if you grab one of the ones whose
          language you can make out, all that really matters is Figure 2
          (p. 7 in the French version, for example). It's not exactly
          the same, but I sense a similarity in the intent, especially
          in terms of making clear WHO is making the statement. FRAD
          adds one more thing, which is under which rules the statement
          is being made. I could imagine, therefore, BIBFRAME
          authorities looking much like OA if FRAD is adopted.<br>
          <br>
          <br>
          <div class="moz-cite-prefix">On 5/5/13 2:17 AM, Robert
            Sanderson wrote:<br>
          </div>
          <blockquote
cite="mid:[log in to unmask]"
            type="cite">
            <div dir="ltr"><br>
              <div class="gmail_extra">
                <div class="gmail_quote">
                  <div style="">Agreed, however these were simply to
                    demonstrate that annotations expressed in RDF
                    require more than a single reified triple, to refute
                    the claim that we're simply reinventing RDF graphs.
                    Â There needs to be an ontology and defined
                    structure.</div>
                </div>
              </div>
            </div>
          </blockquote>
          <br>
          Yes, and this is bringing up for me some work I'm doing around
          the Dublin Core Application Profiles [2]. I need to catch some
          other folks to have a discussion of this, but will get back to
          you if anything interesting arises.
          <blockquote
cite="mid:[log in to unmask]"
            type="cite">
            <div dir="ltr">
              <div class="gmail_extra">
                <div class="gmail_quote">
                  <div>
                    <div>Yes, definitely.  The cataloguing type of use
                      cases I would see as clearly annotations:</div>
                    <div><br>
                    </div>
                    <div>* Reviews / Notes</div>
                    <div>* Tagging / Subject classification<br>
                    </div>
                    <div>* Citations</div>
                  </div>
                  <div><br>
                  </div>
                  <div style="">Essentially, when the information is
                    provided by a third party, then it would be good to
                    be expressed as an Annotation such that the
                    provenance information is maintained and is
                    compatible with other systems that use Open
                    Annotation.</div>
                </div>
              </div>
            </div>
          </blockquote>
          <br>
          I'm still having a hard time with the dividing line between
          stuff and annotations of stuff. A recent article explaining
          the OA concept [3] said:<br>
          <br>
          Â "Annotations describe resources with additional information,
          which is valu-<br>
          Â Â Â  able to other users, who are searching and browsing
          resource collections."<br>
          <br>
          If you have "additional information" then there must be
          "non-additional information" -- and if you have a third party
          then there must be a first party (the second seems to get
          skipped over in that analogy). I don't think this is a
          generalizable question (one person's "additional"... etc.),
          but at least for any community like libraries some definition
          is going to be needed if annotations will have some
          operational meaning. That's what I think is not clear (yet) in
          the BIBFRAME document. I suspect that the division in library
          data will be based on provenance, but that's not how BIBFRAME
          defines annotation.<br>
          <br>
          <blockquote
cite="mid:[log in to unmask]"
            type="cite">
            <div dir="ltr">
              <div class="gmail_extra">
                <div class="gmail_quote"><br>
                  <div><br>
                  </div>
                  <div style="">The point I was trying to make is that
                    the bibframe annotation model has a property
                    bf:annotationBodyLiteral, which has a literal as the
                    object.  The Open Annotation model explicitly does
                    not allow this, for several important and well
                    discussed reasons.  Thus a point where the two
                    models are not compatible.</div>
                </div>
              </div>
            </div>
          </blockquote>
          <br>
          Right. But then again, DC types doesn't include "literal" as a
          type. The whole typing thing is something I would need to
          think about more. If your only interest is literal v. URI,
          then the BIBFRAME choice is fine. If you have a video or sound
          file, that would be a URI. Something that is interesting in
          the OA model is that it allows you to make statements about
          the thing the URI points to [e.g. annotating a particular
          coordinate area on a map]. I hadn't thought about that, and
          now will have to go back to the OA document and see where that
          fits in. This is one of those areas where the "meta" aspect of
          library data has an affect. Must think more.....<br>
          <br>
          <blockquote
cite="mid:[log in to unmask]"
            type="cite">
            <div dir="ltr">
              <div class="gmail_extra">
                <div class="gmail_quote"><br>
                  <div><br>
                  </div>
                  <blockquote class="gmail_quote" style="margin:0px 0px
                    0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
                    <div bgcolor="#FFFFFF" text="#000000"> Note that
                      there is nothing about library data that would
                      prevent anyone from applying an Open Annotation to
                      the data. The question is, do we want this to be
                      the only way to, for example, assign a subject
                      heading to a Work? OrI wouldn't assume that the
                      BIBFRAME data will exist *as is* in the open
                      world. </div>
                  </blockquote>
                  <div><br>
                  </div>
                  <div style="">Then I would seriously question why RDF
                    is being used at all.</div>
                </div>
              </div>
            </div>
          </blockquote>
          <br>
          I see this differently, perhaps because of my work on
          Application Profiles. I think that many communities will have
          an internal view of their data, and another "face" that they
          present to the open world. The basic structure of RDF, that
          is, triples, and the use of defined ontologies, is a good way
          to organize data whether it is open or not. In fact, there are
          enterprise uses of linked data. Modeling your enterprise data
          on RDF makes it much more likely that you will be able to
          extract a public view. In the Dublin Core arena we are looking
          at Application Profiles as a way to add the constraints that
          are needed within a community or enterprise that has some
          non-open needs, while easily allowing the derivation of an
          open view.<br>
          <br>
          <blockquote
cite="mid:[log in to unmask]"
            type="cite">
            <div dir="ltr">
              <div class="gmail_extra">
                <div class="gmail_quote">
                  <div> </div>
                  <div style="">Was the choice of annotation as a model
                    discussed on this list (and hence available in the
                    archives) or was it simply presented fait accompli?</div>
                </div>
              </div>
            </div>
          </blockquote>
          <br>
          Rob, what you and I are doing here is the full extent of our
          ability to interact in the BIBFRAME process. If you look at
          the "Contribute" page [4] of BIBFRAME you will see that the
          only involvement for the community in the BIBFRAME development
          is discussion on this list. Discussion that, like this thread,
          takes place generally between list members with no direct
          involvement in BIBFRAME development. I would have simply
          replied to you individually, but I'm of the mind that a few
          readers on the list might find our musings interesting. In
          terms of having any influence over the development of
          BIBFRAME, I have no such conceit.<br>
          <br>
          kc<br>
          <br>
          [1]
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.ifla.org/publications/functional-requirements-for-authority-data">http://www.ifla.org/publications/functional-requirements-for-authority-data</a><br>
          [2] <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://dublincore.org/documents/dc-dsp/">http://dublincore.org/documents/dc-dsp/</a><br>
          [3]
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.springer.com/computer/information+systems+and+applications/journal/11042">http://www.springer.com/computer/information+systems+and+applications/journal/11042</a><br>
          [4] <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://bibframe.org/contribute/">http://bibframe.org/contribute/</a><br>
          <pre class="moz-signature" cols="72">-- 
Karen Coyle
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:[log in to unmask]">[log in to unmask]</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://kcoyle.net">http://kcoyle.net</a>
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet</pre>
        </div>
      </blockquote>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Karen Coyle
<a class="moz-txt-link-abbreviated" href="mailto:[log in to unmask]">[log in to unmask]</a> <a class="moz-txt-link-freetext" href="http://kcoyle.net">http://kcoyle.net</a>
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet</pre>
  </body>
</html>

--------------040000020202030108050901--

------------------------------

Date:    Sun, 5 May 2013 16:21:49 +0000
From:    "Cole, Timothy W" <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

Karen-

I empathize with your text, "I'm still having a hard time with the dividing=
 line between stuff and annotations of stuff." =20

4 years ago at the outset of the Open Annotation Collaboration, I started o=
ut thinking that there was need for bright (or at least a fuzzy-bright) lin=
e there. However, I'm not sure now that there is.  Being able to work with =
annotations sometimes as annotations of stuff and sometimes as stuff in the=
ir own right is proving a very powerful approach in practice. The evolution=
 of the Open Annotation data model has been heavily influenced by experimen=
tation, including some experimentation at Illinois (and elsewhere) with ann=
otation of library resources (including authorities) and bibliographic info=
rmation derived from MARC and from other sources. I've been struck how not =
useful maintaining an unequivocal distinction between annotations of stuff =
and stuff turns out to be in practice. A bit like the question in physics a=
bout whether light is a wave or a particle. It depends.

I also should say that our experimental experience over the last few years =
has heavily influenced a number of decisions intrinsic to the current Open =
Annotation data model, including the decisions about not including a 'hasLi=
teralBody' predicate and not trying to express the motivation of an annotat=
ion through sub-classing (myself and other librarians here at Illinois were=
 on the other side of this issue for quite a while, but came around in ligh=
t of our own experimentation showing that this just did not work well in pr=
actice). At Illinois we're now moving forward this summer on a brand new pr=
oject within the HathTrust Research Center that will make extensive use of =
annotations conforming to the Open Annotation model, both in the curation o=
f the bibliographic records and authorities and is the curation of the full=
 text. We'll learn more, I'm sure, but it's definitely the right way for us=
 to be going right now.

While I take your earlier point that BIBFRAME's is coming at annotation fro=
m its own unique perspective, I do think there is overlap with the use case=
s encompassed by Open Annotation, and I anticipate that some of the experim=
entation and testing done leading up to the Open Annotation data model migh=
t resonate with some of the BIBFRAME annotation use cases (though of course=
 I understand that in other instances it might not).=20

Thanks,

Tim Cole
University of Illinois at UC.


________________________________________
From: Bibliographic Framework Transition Initiative Forum [BIBFRAME@LISTSER=
V.LOC.GOV] on behalf of Karen Coyle [[log in to unmask]]
Sent: Sunday, May 05, 2013 10:26
To: [log in to unmask]
Subject: Re: [BIBFRAME] Annotations (Was: Documents and improvements)

Jeff, I'm thinking about the part of FRAD that is outside of the main box (=
which I think may be handled by SKOS). There are some structures that modif=
y (or, annotate) the authority data:

First, there is a "box" with:
 - name
 - identifier

Both of these are SKOS-able, I believe.

That "box" itself is modified with:
  - Access point
  -- Rules (for access point)
  --- Agency (that applied the rules)

It is this last part that looks OA-ish to me. This goes beyond what you hav=
e in VIAF, which contains an identifier for the original source, but doesn'=
t separate access points from identities (as far as I can tell), and doesn'=
t include rules. The Agency covered by the source URI is implied, but if yo=
u have something like NACO you may want the actual agency that made the dec=
ision (040 $a or something like that).

kc



On 5/5/13 8:05 AM, Young,Jeff (OR) wrote:
Or SKOS for that matter...

Sent from my iPad

On May 5, 2013, at 11:03 AM, "Karen Coyle" <[log in to unmask]<mailto:lists@K=
COYLE.NET>> wrote:

Rob - thanks for your comments, and just a few more of mine. I'll try to re=
duce things down a bit.

First, it has occurred to me that, perhaps ironically, the "Functional Requ=
irements for Authority Data", FRAD, [1] is very close to OA. Unfortunately,=
 the English version isn't available online, but if you grab one of the one=
s whose language you can make out, all that really matters is Figure 2 (p. =
7 in the French version, for example). It's not exactly the same, but I sen=
se a similarity in the intent, especially in terms of making clear WHO is m=
aking the statement. FRAD adds one more thing, which is under which rules t=
he statement is being made. I could imagine, therefore, BIBFRAME authoritie=
s looking much like OA if FRAD is adopted.


On 5/5/13 2:17 AM, Robert Sanderson wrote:

Agreed, however these were simply to demonstrate that annotations expressed=
 in RDF require more than a single reified triple, to refute the claim that=
 we're simply reinventing RDF graphs.  There needs to be an ontology and de=
fined structure.

Yes, and this is bringing up for me some work I'm doing around the Dublin C=
ore Application Profiles [2]. I need to catch some other folks to have a di=
scussion of this, but will get back to you if anything interesting arises.
Yes, definitely.  The cataloguing type of use cases I would see as clearly =
annotations:

* Reviews / Notes
* Tagging / Subject classification
* Citations

Essentially, when the information is provided by a third party, then it wou=
ld be good to be expressed as an Annotation such that the provenance inform=
ation is maintained and is compatible with other systems that use Open Anno=
tation.

I'm still having a hard time with the dividing line between stuff and annot=
ations of stuff. A recent article explaining the OA concept [3] said:

 "Annotations describe resources with additional information, which is valu=
-
    able to other users, who are searching and browsing resource collection=
s."

If you have "additional information" then there must be "non-additional inf=
ormation" -- and if you have a third party then there must be a first party=
 (the second seems to get skipped over in that analogy). I don't think this=
 is a generalizable question (one person's "additional"... etc.), but at le=
ast for any community like libraries some definition is going to be needed =
if annotations will have some operational meaning. That's what I think is n=
ot clear (yet) in the BIBFRAME document. I suspect that the division in lib=
rary data will be based on provenance, but that's not how BIBFRAME defines =
annotation.



The point I was trying to make is that the bibframe annotation model has a =
property bf:annotationBodyLiteral, which has a literal as the object.  The =
Open Annotation model explicitly does not allow this, for several important=
 and well discussed reasons.  Thus a point where the two models are not com=
patible.

Right. But then again, DC types doesn't include "literal" as a type. The wh=
ole typing thing is something I would need to think about more. If your onl=
y interest is literal v. URI, then the BIBFRAME choice is fine. If you have=
 a video or sound file, that would be a URI. Something that is interesting =
in the OA model is that it allows you to make statements about the thing th=
e URI points to [e.g. annotating a particular coordinate area on a map]. I =
hadn't thought about that, and now will have to go back to the OA document =
and see where that fits in. This is one of those areas where the "meta" asp=
ect of library data has an affect. Must think more.....



Note that there is nothing about library data that would prevent anyone fro=
m applying an Open Annotation to the data. The question is, do we want this=
 to be the only way to, for example, assign a subject heading to a Work? Or=
I wouldn't assume that the BIBFRAME data will exist *as is* in the open wor=
ld.

Then I would seriously question why RDF is being used at all.

I see this differently, perhaps because of my work on Application Profiles.=
 I think that many communities will have an internal view of their data, an=
d another "face" that they present to the open world. The basic structure o=
f RDF, that is, triples, and the use of defined ontologies, is a good way t=
o organize data whether it is open or not. In fact, there are enterprise us=
es of linked data. Modeling your enterprise data on RDF makes it much more =
likely that you will be able to extract a public view. In the Dublin Core a=
rena we are looking at Application Profiles as a way to add the constraints=
 that are needed within a community or enterprise that has some non-open ne=
eds, while easily allowing the derivation of an open view.


Was the choice of annotation as a model discussed on this list (and hence a=
vailable in the archives) or was it simply presented fait accompli?

Rob, what you and I are doing here is the full extent of our ability to int=
eract in the BIBFRAME process. If you look at the "Contribute" page [4] of =
BIBFRAME you will see that the only involvement for the community in the BI=
BFRAME development is discussion on this list. Discussion that, like this t=
hread, takes place generally between list members with no direct involvemen=
t in BIBFRAME development. I would have simply replied to you individually,=
 but I'm of the mind that a few readers on the list might find our musings =
interesting. In terms of having any influence over the development of BIBFR=
AME, I have no such conceit.

kc

[1] http://www.ifla.org/publications/functional-requirements-for-authority-=
data
[2] http://dublincore.org/documents/dc-dsp/
[3] http://www.springer.com/computer/information+systems+and+applications/j=
ournal/11042
[4] http://bibframe.org/contribute/

--
Karen Coyle
[log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet


--
Karen Coyle
[log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

------------------------------

Date:    Sun, 5 May 2013 12:33:03 -0400
From:    "Young,Jeff (OR)" <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

--Apple-Mail-576F2FAD-2EE0-4BE2-A604-D395CE5DD5B2
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64

SXQncyBoYXJkIHRvIHN5bXBhdGhpemUgd2l0aCBhIHZpZXcgdGhhdCB3YW50cyB0byBlbmdpbmVl
ciBhY2Nlc3MgcG9pbnRzIGZpcnN0IGFuZCB0aGUgdGhpbmdzIHRoZW1zZWx2ZXMgbGF0ZXIuIElz
IGJpcnRoIGRhdGUgYSBwcm9wZXJ0eSBvZiB0aGUgYWNjZXNzIHBvaW50IG9yIHRoZSB0aGluZyBp
dHNlbGY/IE1BRFMsIGZvciBleGFtcGxlLCBjbGVhcmx5IGJlbGlldmVzIGl0cyB0aGUgZm9ybWVy
LiBOb3RpY2UgdGhhdCBMQ05BRiBkb2Vzbid0IGV2ZW4gYm90aGVyIHRvIGlkZW50aWZ5IHRoZSB0
aGluZyBpdHNlbGYuIFRoaXMgY2FtZSB1cCBhIHdoaWxlIGJhY2sgYW5kIHRoZXJlIHdhcyBzb21l
IG11bWJvIGp1bWJvIGFib3V0ICJpbmZlcmVuY2luZyIuIA0KDQpOb3RlIHRoYXQgU0tPUyB3YXMg
ZGVzaWduZWQgdG8gYmUgYSBicmlkZ2UgdG8gaGVscCB1cyBtb3ZlIGF3YXkgZnJvbSBvdXIgZGVw
ZW5kZW5jeSBvbiBzdHJpbmdzIGFuZCB0b3dhcmRzIGlkZW50aWZpYWJsZSB0aGluZ3MuIFNvbWVo
b3cgd2UgdHdpc3QgdGhhdCBpbnRvIHRyZWF0aW5nIHN0cmluZ3MgYXMgbW9kZWxlZCB0aGluZ3Mg
aW5zdGVhZC4gQW5ub3RhdGlvbnMgc2VlbSB0byBzdWZmZXIgZnJvbSB0aGlzIHNhbWUgInN0cnVj
dHVyZWQgc3RyaW5nIiBkaXNlYXNlLCB3aGljaCBpcyBwcmVzdW1hYmx5IGhvdyB0aGlzIHRocmVh
ZCBnb3QgZnJvbSBBIHRvIEIuDQoNCk5ldmVydGhlbGVzcywgSSB3aWxsIGFkbWl0IHRoYXQgc3Ry
aW5nIGNvbnNpc3RlbmN5IGlzIGltcG9ydGFudC4gSU1PLCB0aGUgImFjY2VzcyBwb2ludCIgcHJl
c3VtYWJseSBtYXBzIHRvIHNrb3M6cHJlZkxhYmVsLCB0aGUgImFnZW5jeSIgY291bGQgbWFwIHRv
IHRoZSBkYzpjcmVhdG9yIG9mIHRoZSBza29zOkNvbmNlcHRTY2hlbWUsIGFuZCB0aGUgcnVsZXMg
Y291bGQgYmUgYXR0YWNoZWQgdG8gZWl0aGVyIHRoZSBza29zOkNvbmNlcHRTY2hlbWUgZW50aXR5
IG9yIGluZGl2aWR1YWwgc2tvczpDb25jZXB0cyB1c2luZyBzb21lIHByb3BlcnR5IHRoYXQgU0tP
UyBvciBNQURTIG9yIHNvbWVib2R5IHNvbWV3aGVyZSBpcyBhbHJlYWR5IHVzaW5nIGZvciB0aGlz
IHB1cnBvc2UuIEl0J3MgcmVhbGx5IGhhcmQgdG8gbG92ZSBoZWF2eXdlaWdodCBydWxlcyBmb3Ig
c3RyaW5ncywgdGhvdWdoLCBlc3BlY2lhbGx5IGhlYXZpbHkgc3RydWN0dXJlZCBzdHJpbmdzLg0K
DQpBcyBhIGNvbnN1bWVyLCB3aGF0IEknbSBtb3N0bHkgaW50ZXJlc3RlZCBpbiBhcmUgdGhlIHJl
YWwgdGhpbmdzIGJlaW5nIHN5bWJvbGl6ZWQgYnkgdGhlIGFjY2VzcyBwb2ludHMuIFRoYXQncyB3
aGF0IGZvYWY6Zm9jdXMgaXMgdXNlZCBmb3IuIFRoYXQncyB0aGUgdGhpbmcgdGhhdCBkZXNlcnZl
cyBhIGJpcnRoIGRhdGUuDQoNCkplZmYNCg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gTWF5IDUs
IDIwMTMsIGF0IDExOjI3IEFNLCAiS2FyZW4gQ295bGUiIDxsaXN0c0BLQ09ZTEUuTkVUPiB3cm90
ZToNCg0KPiBKZWZmLCBJJ20gdGhpbmtpbmcgYWJvdXQgdGhlIHBhcnQgb2YgRlJBRCB0aGF0IGlz
IG91dHNpZGUgb2YgdGhlIG1haW4gYm94ICh3aGljaCBJIHRoaW5rIG1heSBiZSBoYW5kbGVkIGJ5
IFNLT1MpLiBUaGVyZSBhcmUgc29tZSBzdHJ1Y3R1cmVzIHRoYXQgbW9kaWZ5IChvciwgYW5ub3Rh
dGUpIHRoZSBhdXRob3JpdHkgZGF0YToNCj4gDQo+IEZpcnN0LCB0aGVyZSBpcyBhICJib3giIHdp
dGg6DQo+IMOCIC0gbmFtZQ0KPiDDgiAtIGlkZW50aWZpZXINCj4gDQo+IEJvdGggb2YgdGhlc2Ug
YXJlIFNLT1MtYWJsZSwgSSBiZWxpZXZlLg0KPiANCj4gVGhhdCAiYm94IiBpdHNlbGYgaXMgbW9k
aWZpZWQgd2l0aDoNCj4gw4IgIC0gQWNjZXNzIHBvaW50DQo+IMOCICAtLSBSdWxlcyAoZm9yIGFj
Y2VzcyBwb2ludCkNCj4gw4IgIC0tLSBBZ2VuY3kgKHRoYXQgYXBwbGllZCB0aGUgcnVsZXMpDQo+
IA0KPiBJdCBpcyB0aGlzIGxhc3QgcGFydCB0aGF0IGxvb2tzIE9BLWlzaCB0byBtZS4gVGhpcyBn
b2VzIGJleW9uZCB3aGF0IHlvdSBoYXZlIGluIFZJQUYsIHdoaWNoIGNvbnRhaW5zIGFuIGlkZW50
aWZpZXIgZm9yIHRoZSBvcmlnaW5hbCBzb3VyY2UsIGJ1dCBkb2Vzbid0IHNlcGFyYXRlIGFjY2Vz
cyBwb2ludHMgZnJvbSBpZGVudGl0aWVzIChhcyBmYXIgYXMgSSBjYW4gdGVsbCksIGFuZCBkb2Vz
bid0IGluY2x1ZGUgcnVsZXMuIFRoZSBBZ2VuY3kgY292ZXJlZCBieSB0aGUgc291cmNlIFVSSSBp
cyBpbXBsaWVkLCBidXQgaWYgeW91IGhhdmUgc29tZXRoaW5nIGxpa2UgTkFDTyB5b3UgbWF5IHdh
bnQgdGhlIGFjdHVhbCBhZ2VuY3kgdGhhdCBtYWRlIHRoZSBkZWNpc2lvbiAoMDQwICRhIG9yIHNv
bWV0aGluZyBsaWtlIHRoYXQpLg0KPiANCj4ga2MNCj4gDQo+IA0KPiANCj4gT24gNS81LzEzIDg6
MDUgQU0sIFlvdW5nLEplZmYgKE9SKSB3cm90ZToNCj4+IE9yIFNLT1MgZm9yIHRoYXQgbWF0dGVy
Li4uDQo+PiANCj4+IFNlbnQgZnJvbSBteSBpUGFkDQo+PiANCj4+IE9uIE1heSA1LCAyMDEzLCBh
dCAxMTowMyBBTSwgIkthcmVuIENveWxlIiA8bGlzdHNAS0NPWUxFLk5FVD4gd3JvdGU6DQo+PiAN
Cj4+PiBSb2IgLSB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMsIGFuZCBqdXN0IGEgZmV3IG1vcmUg
b2YgbWluZS4gSSdsbCB0cnkgdG8gcmVkdWNlIHRoaW5ncyBkb3duIGEgYml0Lg0KPj4+IA0KPj4+
IEZpcnN0LCBpdCBoYXMgb2NjdXJyZWQgdG8gbWUgdGhhdCwgcGVyaGFwcyBpcm9uaWNhbGx5LCB0
aGUgIkZ1bmN0aW9uYWwgUmVxdWlyZW1lbnRzIGZvciBBdXRob3JpdHkgRGF0YSIsIEZSQUQsIFsx
XSBpcyB2ZXJ5IGNsb3NlIHRvIE9BLiBVbmZvcnR1bmF0ZWx5LCB0aGUgRW5nbGlzaCB2ZXJzaW9u
IGlzbid0IGF2YWlsYWJsZSBvbmxpbmUsIGJ1dCBpZiB5b3UgZ3JhYiBvbmUgb2YgdGhlIG9uZXMg
d2hvc2UgbGFuZ3VhZ2UgeW91IGNhbiBtYWtlIG91dCwgYWxsIHRoYXQgcmVhbGx5IG1hdHRlcnMg
aXMgRmlndXJlIDIgKHAuIDcgaW4gdGhlIEZyZW5jaCB2ZXJzaW9uLCBmb3IgZXhhbXBsZSkuIEl0
J3Mgbm90IGV4YWN0bHkgdGhlIHNhbWUsIGJ1dCBJIHNlbnNlIGEgc2ltaWxhcml0eSBpbiB0aGUg
aW50ZW50LCBlc3BlY2lhbGx5IGluIHRlcm1zIG9mIG1ha2luZyBjbGVhciBXSE8gaXMgbWFraW5n
IHRoZSBzdGF0ZW1lbnQuIEZSQUQgYWRkcyBvbmUgbW9yZSB0aGluZywgd2hpY2ggaXMgdW5kZXIg
d2hpY2ggcnVsZXMgdGhlIHN0YXRlbWVudCBpcyBiZWluZyBtYWRlLiBJIGNvdWxkIGltYWdpbmUs
IHRoZXJlZm9yZSwgQklCRlJBTUUgYXV0aG9yaXRpZXMgbG9va2luZyBtdWNoIGxpa2UgT0EgaWYg
RlJBRCBpcyBhZG9wdGVkLg0KPj4+IA0KPj4+IA0KPj4+IE9uIDUvNS8xMyAyOjE3IEFNLCBSb2Jl
cnQgU2FuZGVyc29uIHdyb3RlOg0KPj4+PiANCj4+Pj4gQWdyZWVkLCBob3dldmVyIHRoZXNlIHdl
cmUgc2ltcGx5IHRvIGRlbW9uc3RyYXRlIHRoYXQgYW5ub3RhdGlvbnMgZXhwcmVzc2VkIGluIFJE
RiByZXF1aXJlIG1vcmUgdGhhbiBhIHNpbmdsZSByZWlmaWVkIHRyaXBsZSwgdG8gcmVmdXRlIHRo
ZSBjbGFpbSB0aGF0IHdlJ3JlIHNpbXBseSByZWludmVudGluZyBSREYgZ3JhcGhzLiDDgiBUaGVy
ZSBuZWVkcyB0byBiZSBhbiBvbnRvbG9neSBhbmQgZGVmaW5lZCBzdHJ1Y3R1cmUuDQo+Pj4gDQo+
Pj4gWWVzLCBhbmQgdGhpcyBpcyBicmluZ2luZyB1cCBmb3IgbWUgc29tZSB3b3JrIEknbSBkb2lu
ZyBhcm91bmQgdGhlIER1YmxpbiBDb3JlIEFwcGxpY2F0aW9uIFByb2ZpbGVzIFsyXS4gSSBuZWVk
IHRvIGNhdGNoIHNvbWUgb3RoZXIgZm9sa3MgdG8gaGF2ZSBhIGRpc2N1c3Npb24gb2YgdGhpcywg
YnV0IHdpbGwgZ2V0IGJhY2sgdG8geW91IGlmIGFueXRoaW5nIGludGVyZXN0aW5nIGFyaXNlcy4N
Cj4+Pj4gDQo+Pj4+IFllcywgZGVmaW5pdGVseS4gw4IgVGhlIGNhdGFsb2d1aW5nIHR5cGUgb2Yg
dXNlIGNhc2VzIEkgd291bGQgc2VlIGFzIGNsZWFybHkgYW5ub3RhdGlvbnM6DQo+Pj4+IA0KPj4+
PiAqIFJldmlld3MgLyBOb3Rlcw0KPj4+PiAqIFRhZ2dpbmcgLyBTdWJqZWN0IGNsYXNzaWZpY2F0
aW9uDQo+Pj4+ICogQ2l0YXRpb25zDQo+Pj4+IA0KPj4+PiBFc3NlbnRpYWxseSwgd2hlbiB0aGUg
aW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgYnkgYSB0aGlyZCBwYXJ0eSwgdGhlbiBpdCB3b3VsZCBi
ZSBnb29kIHRvIGJlIGV4cHJlc3NlZCBhcyBhbiBBbm5vdGF0aW9uIHN1Y2ggdGhhdCB0aGUgcHJv
dmVuYW5jZSBpbmZvcm1hdGlvbiBpcyBtYWludGFpbmVkIGFuZCBpcyBjb21wYXRpYmxlIHdpdGgg
b3RoZXIgc3lzdGVtcyB0aGF0IHVzZSBPcGVuIEFubm90YXRpb24uDQo+Pj4gDQo+Pj4gSSdtIHN0
aWxsIGhhdmluZyBhIGhhcmQgdGltZSB3aXRoIHRoZSBkaXZpZGluZyBsaW5lIGJldHdlZW4gc3R1
ZmYgYW5kIGFubm90YXRpb25zIG9mIHN0dWZmLiBBIHJlY2VudCBhcnRpY2xlIGV4cGxhaW5pbmcg
dGhlIE9BIGNvbmNlcHQgWzNdIHNhaWQ6DQo+Pj4gDQo+Pj4gw4IgIkFubm90YXRpb25zIGRlc2Ny
aWJlIHJlc291cmNlcyB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHZhbHUt
DQo+Pj4gw4Igw4Igw4IgIGFibGUgdG8gb3RoZXIgdXNlcnMsIHdobyBhcmUgc2VhcmNoaW5nIGFu
ZCBicm93c2luZyByZXNvdXJjZSBjb2xsZWN0aW9ucy4iDQo+Pj4gDQo+Pj4gSWYgeW91IGhhdmUg
ImFkZGl0aW9uYWwgaW5mb3JtYXRpb24iIHRoZW4gdGhlcmUgbXVzdCBiZSAibm9uLWFkZGl0aW9u
YWwgaW5mb3JtYXRpb24iIC0tIGFuZCBpZiB5b3UgaGF2ZSBhIHRoaXJkIHBhcnR5IHRoZW4gdGhl
cmUgbXVzdCBiZSBhIGZpcnN0IHBhcnR5ICh0aGUgc2Vjb25kIHNlZW1zIHRvIGdldCBza2lwcGVk
IG92ZXIgaW4gdGhhdCBhbmFsb2d5KS4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgZ2VuZXJhbGl6
YWJsZSBxdWVzdGlvbiAob25lIHBlcnNvbidzICJhZGRpdGlvbmFsIi4uLiBldGMuKSwgICAgICAg
ICAgIGJ1dCBhdCBsZWFzdCBmb3IgYW55IGNvbW11bml0eSBsaWtlIGxpYnJhcmllcyBzb21lIGRl
ZmluaXRpb24gaXMgZ29pbmcgdG8gYmUgbmVlZGVkIGlmIGFubm90YXRpb25zIHdpbGwgaGF2ZSBz
b21lIG9wZXJhdGlvbmFsIG1lYW5pbmcuIFRoYXQncyB3aGF0IEkgdGhpbmsgaXMgbm90IGNsZWFy
ICh5ZXQpIGluIHRoZSBCSUJGUkFNRSBkb2N1bWVudC4gSSBzdXNwZWN0IHRoYXQgdGhlIGRpdmlz
aW9uIGluIGxpYnJhcnkgZGF0YSB3aWxsIGJlIGJhc2VkIG9uIHByb3ZlbmFuY2UsIGJ1dCB0aGF0
J3Mgbm90IGhvdyBCSUJGUkFNRSBkZWZpbmVzIGFubm90YXRpb24uDQo+Pj4gDQo+Pj4+IA0KPj4+
PiANCj4+Pj4gVGhlIHBvaW50IEkgd2FzIHRyeWluZyB0byBtYWtlIGlzIHRoYXQgdGhlIGJpYmZy
YW1lIGFubm90YXRpb24gbW9kZWwgaGFzIGEgcHJvcGVydHkgYmY6YW5ub3RhdGlvbkJvZHlMaXRl
cmFsLCB3aGljaCBoYXMgYSBsaXRlcmFsIGFzIHRoZSBvYmplY3QuIMOCIFRoZSBPcGVuIEFubm90
YXRpb24gbW9kZWwgZXhwbGljaXRseSBkb2VzIG5vdCBhbGxvdyB0aGlzLCBmb3Igc2V2ZXJhbCBp
bXBvcnRhbnQgYW5kIHdlbGwgZGlzY3Vzc2VkIHJlYXNvbnMuIMOCIFRodXMgYSBwb2ludCB3aGVy
ZSB0aGUgdHdvIG1vZGVscyBhcmUgbm90IGNvbXBhdGlibGUuDQo+Pj4gDQo+Pj4gUmlnaHQuIEJ1
dCB0aGVuIGFnYWluLCBEQyB0eXBlcyBkb2Vzbid0IGluY2x1ZGUgImxpdGVyYWwiIGFzIGEgdHlw
ZS4gVGhlIHdob2xlIHR5cGluZyB0aGluZyBpcyBzb21ldGhpbmcgSSB3b3VsZCBuZWVkIHRvIHRo
aW5rIGFib3V0IG1vcmUuIElmIHlvdXIgb25seSBpbnRlcmVzdCBpcyBsaXRlcmFsIHYuIFVSSSwg
dGhlbiB0aGUgQklCRlJBTUUgY2hvaWNlIGlzIGZpbmUuIElmIHlvdSBoYXZlIGEgdmlkZW8gb3Ig
c291bmQgZmlsZSwgdGhhdCB3b3VsZCBiZSBhIFVSSS4gU29tZXRoaW5nIHRoYXQgaXMgaW50ZXJl
c3RpbmcgaW4gdGhlIE9BIG1vZGVsIGlzIHRoYXQgaXQgYWxsb3dzIHlvdSB0byBtYWtlIHN0YXRl
bWVudHMgYWJvdXQgdGhlIHRoaW5nIHRoZSBVUkkgcG9pbnRzIHRvIFtlLmcuIGFubm90YXRpbmcg
YSBwYXJ0aWN1bGFyIGNvb3JkaW5hdGUgYXJlYSBvbiBhIG1hcF0uIEkgaGFkbid0IHRob3VnaHQg
YWJvdXQgdGhhdCwgYW5kIG5vdyB3aWxsIGhhdmUgdG8gZ28gYmFjayB0byB0aGUgT0EgZG9jdW1l
bnQgYW5kIHNlZSB3aGVyZSB0aGF0IGZpdHMgaW4uIFRoaXMgaXMgb25lIG9mIHRob3NlIGFyZWFz
IHdoZXJlIHRoZSAibWV0YSIgYXNwZWN0IG9mIGxpYnJhcnkgZGF0YSBoYXMgYW4gYWZmZWN0LiBN
dXN0IHRoaW5rIG1vcmUuLi4uLg0KPj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+PiBOb3RlIHRoYXQg
dGhlcmUgaXMgbm90aGluZyBhYm91dCBsaWJyYXJ5IGRhdGEgdGhhdCB3b3VsZCBwcmV2ZW50IGFu
eW9uZSBmcm9tIGFwcGx5aW5nIGFuIE9wZW4gQW5ub3RhdGlvbiB0byB0aGUgZGF0YS4gVGhlIHF1
ZXN0aW9uIGlzLCBkbyB3ZSB3YW50IHRoaXMgdG8gYmUgdGhlIG9ubHkgd2F5IHRvLCBmb3IgZXhh
bXBsZSwgYXNzaWduIGEgc3ViamVjdCBoZWFkaW5nIHRvIGEgV29yaz8gT3JJIHdvdWxkbid0IGFz
c3VtZSB0aGF0IHRoZSBCSUJGUkFNRSBkYXRhIHdpbGwgZXhpc3QgKmFzIGlzKiBpbiB0aGUgb3Bl
biB3b3JsZC4NCj4+Pj4gDQo+Pj4+IFRoZW4gSSB3b3VsZCBzZXJpb3VzbHkgcXVlc3Rpb24gd2h5
IFJERiBpcyBiZWluZyB1c2VkIGF0IGFsbC4NCj4+PiANCj4+PiBJIHNlZSB0aGlzIGRpZmZlcmVu
dGx5LCBwZXJoYXBzIGJlY2F1c2Ugb2YgbXkgd29yayBvbiBBcHBsaWNhdGlvbiBQcm9maWxlcy4g
SSB0aGluayB0aGF0IG1hbnkgY29tbXVuaXRpZXMgd2lsbCBoYXZlIGFuIGludGVybmFsIHZpZXcg
b2YgdGhlaXIgZGF0YSwgYW5kIGFub3RoZXIgImZhY2UiIHRoYXQgdGhleSBwcmVzZW50IHRvIHRo
ZSBvcGVuIHdvcmxkLiBUaGUgYmFzaWMgc3RydWN0dXJlIG9mIFJERiwgdGhhdCBpcywgdHJpcGxl
cywgYW5kIHRoZSB1c2Ugb2YgZGVmaW5lZCBvbnRvbG9naWVzLCBpcyBhIGdvb2Qgd2F5IHRvIG9y
Z2FuaXplIGRhdGEgd2hldGhlciBpdCBpcyBvcGVuIG9yIG5vdC4gSW4gZmFjdCwgdGhlcmUgYXJl
IGVudGVycHJpc2UgdXNlcyBvZiBsaW5rZWQgZGF0YS4gTW9kZWxpbmcgeW91ciBlbnRlcnByaXNl
IGRhdGEgb24gUkRGIG1ha2VzIGl0IG11Y2ggbW9yZSBsaWtlbHkgdGhhdCB5b3Ugd2lsbCBiZSBh
YmxlIHRvIGV4dHJhY3QgYSBwdWJsaWMgdmlldy4gSW4gdGhlIER1YmxpbiBDb3JlIGFyZW5hIHdl
IGFyZSBsb29raW5nIGF0IEFwcGxpY2F0aW9uIFByb2ZpbGVzIGFzIGEgd2F5IHRvIGFkZCB0aGUg
Y29uc3RyYWludHMgdGhhdCBhcmUgbmVlZGVkIHdpdGhpbiBhIGNvbW11bml0eSBvciBlbnRlcnBy
aXNlIHRoYXQgaGFzIHNvbWUgbm9uLW9wZW4gbmVlZHMsIHdoaWxlIGVhc2lseSBhbGxvd2luZyB0
aGUgZGVyaXZhdGlvbiBvZiBhbiBvcGVuIHZpZXcuDQo+Pj4gDQo+Pj4+IMOCIA0KPj4+PiBXYXMg
dGhlIGNob2ljZSBvZiBhbm5vdGF0aW9uIGFzIGEgbW9kZWwgZGlzY3Vzc2VkIG9uIHRoaXMgbGlz
dCAoYW5kIGhlbmNlIGF2YWlsYWJsZSBpbiB0aGUgYXJjaGl2ZXMpIG9yIHdhcyBpdCBzaW1wbHkg
cHJlc2VudGVkIGZhaXQgYWNjb21wbGk/DQo+Pj4gDQo+Pj4gUm9iLCB3aGF0IHlvdSBhbmQgSSBh
cmUgZG9pbmcgaGVyZSBpcyB0aGUgZnVsbCBleHRlbnQgb2Ygb3VyIGFiaWxpdHkgdG8gaW50ZXJh
Y3QgaW4gdGhlIEJJQkZSQU1FIHByb2Nlc3MuIElmIHlvdSBsb29rIGF0IHRoZSAiQ29udHJpYnV0
ZSIgcGFnZSBbNF0gb2YgQklCRlJBTUUgeW91IHdpbGwgc2VlIHRoYXQgdGhlIG9ubHkgaW52b2x2
ZW1lbnQgZm9yIHRoZSBjb21tdW5pdHkgaW4gdGhlIEJJQkZSQU1FIGRldmVsb3BtZW50IGlzIGRp
c2N1c3Npb24gb24gdGhpcyBsaXN0LiBEaXNjdXNzaW9uIHRoYXQsIGxpa2UgdGhpcyB0aHJlYWQs
IHRha2VzIHBsYWNlIGdlbmVyYWxseSBiZXR3ZWVuIGxpc3QgbWVtYmVycyB3aXRoIG5vIGRpcmVj
dCBpbnZvbHZlbWVudCBpbiBCSUJGUkFNRSBkZXZlbG9wbWVudC4gSSB3b3VsZCBoYXZlIHNpbXBs
eSByZXBsaWVkIHRvIHlvdSBpbmRpdmlkdWFsbHksIGJ1dCBJJ20gb2YgdGhlIG1pbmQgdGhhdCBh
IGZldyByZWFkZXJzIG9uIHRoZSBsaXN0IG1pZ2h0IGZpbmQgb3VyIG11c2luZ3MgaW50ZXJlc3Rp
bmcuIEluIHRlcm1zIG9mIGhhdmluZyBhbnkgaW5mbHVlbmNlIG92ZXIgdGhlIGRldmVsb3BtZW50
IG9mIEJJQkZSQU1FLCBJIGhhdmUgbm8gc3VjaCBjb25jZWl0Lg0KPj4+IA0KPj4+IGtjDQo+Pj4g
DQo+Pj4gWzFdIGh0dHA6Ly93d3cuaWZsYS5vcmcvcHVibGljYXRpb25zL2Z1bmN0aW9uYWwtcmVx
dWlyZW1lbnRzLWZvci1hdXRob3JpdHktZGF0YQ0KPj4+IFsyXSBodHRwOi8vZHVibGluY29yZS5v
cmcvZG9jdW1lbnRzL2RjLWRzcC8NCj4+PiBbM10gaHR0cDovL3d3dy5zcHJpbmdlci5jb20vY29t
cHV0ZXIvaW5mb3JtYXRpb24rc3lzdGVtcythbmQrYXBwbGljYXRpb25zL2pvdXJuYWwvMTEwNDIN
Cj4+PiBbNF0gaHR0cDovL2JpYmZyYW1lLm9yZy9jb250cmlidXRlLw0KPj4+IC0tIA0KPj4+IEth
cmVuIENveWxlDQo+Pj4ga2NveWxlQGtjb3lsZS5uZXQgaHR0cDovL2tjb3lsZS5uZXQNCj4+PiBw
aDogMS01MTAtNTQwLTc1OTYNCj4+PiBtOiAxLTUxMC00MzUtODIzNA0KPj4+IHNreXBlOiBrY295
bGVuZXQNCj4gDQo+IC0tIA0KPiBLYXJlbiBDb3lsZQ0KPiBrY295bGVAa2NveWxlLm5ldCBodHRw
Oi8va2NveWxlLm5ldA0KPiBwaDogMS01MTAtNTQwLTc1OTYNCj4gbTogMS01MTAtNDM1LTgyMzQN
Cj4gc2t5cGU6IGtjb3lsZW5ldA0K
--Apple-Mail-576F2FAD-2EE0-4BE2-A604-D395CE5DD5B2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SXQncyBo
YXJkIHRvIHN5bXBhdGhpemUgd2l0aCBhIHZpZXcgdGhhdCB3YW50cyB0byBlbmdpbmVlciBhY2Nl
c3MgcG9pbnRzIGZpcnN0IGFuZCB0aGUgdGhpbmdzIHRoZW1zZWx2ZXMgbGF0ZXIuIElzIGJpcnRo
IGRhdGUgYSBwcm9wZXJ0eSBvZiB0aGUgYWNjZXNzIHBvaW50IG9yIHRoZSB0aGluZyBpdHNlbGY/
IE1BRFMsIGZvciBleGFtcGxlLCBjbGVhcmx5IGJlbGlldmVzIGl0cyB0aGUgZm9ybWVyLiBOb3Rp
Y2UgdGhhdCBMQ05BRiBkb2Vzbid0IGV2ZW4gYm90aGVyIHRvIGlkZW50aWZ5IHRoZSB0aGluZyBp
dHNlbGYuIFRoaXMgY2FtZSB1cCBhIHdoaWxlIGJhY2sgYW5kIHRoZXJlIHdhcyBzb21lIG11bWJv
IGp1bWJvIGFib3V0ICJpbmZlcmVuY2luZyIuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp
dj5Ob3RlIHRoYXQgU0tPUyB3YXMgZGVzaWduZWQgdG8gYmUgYSBicmlkZ2UgdG8gaGVscCB1cyBt
b3ZlIGF3YXkgZnJvbSBvdXIgZGVwZW5kZW5jeSBvbiBzdHJpbmdzIGFuZCB0b3dhcmRzIGlkZW50
aWZpYWJsZSB0aGluZ3MuIFNvbWVob3cgd2UgdHdpc3QgdGhhdCBpbnRvIHRyZWF0aW5nIHN0cmlu
Z3MgYXMgbW9kZWxlZCB0aGluZ3MgaW5zdGVhZC4mbmJzcDs8c3BhbiBzdHlsZT0iLXdlYmtpdC10
YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdlYmtpdC1j
b21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdl
YmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5
KTsgIj5Bbm5vdGF0aW9ucyBzZWVtIHRvIHN1ZmZlciBmcm9tIHRoaXMgc2FtZSAic3RydWN0dXJl
ZCBzdHJpbmciIGRpc2Vhc2UsIHdoaWNoIGlzIHByZXN1bWFibHkgaG93IHRoaXMgdGhyZWFkIGdv
dCBmcm9tIEEgdG8gQi48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5OZXZlcnRoZWxl
c3MsIEkgd2lsbCBhZG1pdCB0aGF0IHN0cmluZyBjb25zaXN0ZW5jeSBpcyBpbXBvcnRhbnQuIElN
TywgdGhlICJhY2Nlc3MgcG9pbnQiIHByZXN1bWFibHkgbWFwcyB0byBza29zOnByZWZMYWJlbCwg
dGhlICJhZ2VuY3kiIGNvdWxkIG1hcCB0byB0aGUgZGM6Y3JlYXRvciBvZiB0aGUgc2tvczpDb25j
ZXB0U2NoZW1lLCBhbmQgdGhlIHJ1bGVzIGNvdWxkIGJlIGF0dGFjaGVkIHRvIGVpdGhlciB0aGUg
c2tvczpDb25jZXB0U2NoZW1lIGVudGl0eSBvciBpbmRpdmlkdWFsIHNrb3M6Q29uY2VwdHMgdXNp
bmcgc29tZSBwcm9wZXJ0eSB0aGF0IFNLT1Mgb3IgTUFEUyBvciBzb21lYm9keSBzb21ld2hlcmUg
aXMgYWxyZWFkeSB1c2luZyBmb3IgdGhpcyBwdXJwb3NlLiBJdCdzIHJlYWxseSBoYXJkIHRvIGxv
dmUgaGVhdnl3ZWlnaHQgcnVsZXMgZm9yIHN0cmluZ3MsIHRob3VnaCwgZXNwZWNpYWxseSBoZWF2
aWx5IHN0cnVjdHVyZWQgc3RyaW5ncy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFzIGEgY29u
c3VtZXIsIHdoYXQgSSdtIG1vc3RseSBpbnRlcmVzdGVkIGluIGFyZSB0aGUgcmVhbCB0aGluZ3Mg
YmVpbmcgc3ltYm9saXplZCBieSB0aGUgYWNjZXNzIHBvaW50cy4gVGhhdCdzIHdoYXQgZm9hZjpm
b2N1cyBpcyB1c2VkIGZvci4gVGhhdCdzIHRoZSB0aGluZyB0aGF0IGRlc2VydmVzIGEgYmlydGgg
ZGF0ZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkplZmY8L2Rpdj48ZGl2Pjxicj5TZW50IGZy
b20gbXkgaVBhZDwvZGl2PjxkaXY+PGJyPk9uIE1heSA1LCAyMDEzLCBhdCAxMToyNyBBTSwgIkth
cmVuIENveWxlIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpc3RzQEtDT1lMRS5ORVQiPmxpc3RzQEtD
T1lMRS5ORVQ8L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiPjxkaXY+DQogIA0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYt
OCIgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4NCiAgDQogIA0KICAgIEplZmYsIEknbSB0aGlu
a2luZyBhYm91dCB0aGUgcGFydCBvZiBGUkFEIHRoYXQgaXMgb3V0c2lkZSBvZiB0aGUNCiAgICBt
YWluIGJveCAod2hpY2ggSSB0aGluayBtYXkgYmUgaGFuZGxlZCBieSBTS09TKS4gVGhlcmUgYXJl
IHNvbWUNCiAgICBzdHJ1Y3R1cmVzIHRoYXQgbW9kaWZ5IChvciwgYW5ub3RhdGUpIHRoZSBhdXRo
b3JpdHkgZGF0YTo8YnI+DQogICAgPGJyPg0KICAgIEZpcnN0LCB0aGVyZSBpcyBhICJib3giIHdp
dGg6PGJyPg0KICAgIMOCJm5ic3A7LSBuYW1lPGJyPg0KICAgIMOCJm5ic3A7LSBpZGVudGlmaWVy
PGJyPg0KICAgIDxicj4NCiAgICBCb3RoIG9mIHRoZXNlIGFyZSBTS09TLWFibGUsIEkgYmVsaWV2
ZS48YnI+DQogICAgPGJyPg0KICAgIFRoYXQgImJveCIgaXRzZWxmIGlzIG1vZGlmaWVkIHdpdGg6
PGJyPg0KICAgIMOCJm5ic3A7IC0gQWNjZXNzIHBvaW50PGJyPg0KICAgIMOCJm5ic3A7IC0tIFJ1
bGVzIChmb3IgYWNjZXNzIHBvaW50KTxicj4NCiAgICDDgiZuYnNwOyAtLS0gQWdlbmN5ICh0aGF0
IGFwcGxpZWQgdGhlIHJ1bGVzKTxicj4NCiAgICA8YnI+DQogICAgSXQgaXMgdGhpcyBsYXN0IHBh
cnQgdGhhdCBsb29rcyBPQS1pc2ggdG8gbWUuIFRoaXMgZ29lcyBiZXlvbmQgd2hhdA0KICAgIHlv
dSBoYXZlIGluIFZJQUYsIHdoaWNoIGNvbnRhaW5zIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBvcmln
aW5hbA0KICAgIHNvdXJjZSwgYnV0IGRvZXNuJ3Qgc2VwYXJhdGUgYWNjZXNzIHBvaW50cyBmcm9t
IGlkZW50aXRpZXMgKGFzIGZhcg0KICAgIGFzIEkgY2FuIHRlbGwpLCBhbmQgZG9lc24ndCBpbmNs
dWRlIHJ1bGVzLiBUaGUgQWdlbmN5IGNvdmVyZWQgYnkgdGhlDQogICAgc291cmNlIFVSSSBpcyBp
bXBsaWVkLCBidXQgaWYgeW91IGhhdmUgc29tZXRoaW5nIGxpa2UgTkFDTyB5b3UgbWF5DQogICAg
d2FudCB0aGUgYWN0dWFsIGFnZW5jeSB0aGF0IG1hZGUgdGhlIGRlY2lzaW9uICgwNDAgJGEgb3Ig
c29tZXRoaW5nDQogICAgbGlrZSB0aGF0KS48YnI+DQogICAgPGJyPg0KICAgIGtjPGJyPg0KICAg
IDxicj4NCiAgICA8YnI+DQogICAgPGJyPg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZp
eCI+T24gNS81LzEzIDg6MDUgQU0sIFlvdW5nLEplZmYgKE9SKQ0KICAgICAgd3JvdGU6PGJyPg0K
ICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlIGNpdGU9Im1pZDowQUU5MDgxMS04NUM1LTRDODAt
QkQ5My0wRDQyNDFEQUIwMTFAb2NsYy5vcmciIHR5cGU9ImNpdGUiPg0KICAgICAgPG1ldGEgaHR0
cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgi
Pg0KICAgICAgPGRpdj5PciBTS09TIGZvciB0aGF0IG1hdHRlci4uLjxicj4NCiAgICAgICAgPGJy
Pg0KICAgICAgICBTZW50IGZyb20gbXkgaVBhZDwvZGl2Pg0KICAgICAgPGRpdj48YnI+DQogICAg
ICAgIE9uIE1heSA1LCAyMDEzLCBhdCAxMTowMyBBTSwgIkthcmVuIENveWxlIiAmbHQ7PGEgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86bGlzdHNAS0NPWUxFLk5FVCI+bGlzdHNA
S0NPWUxFLk5FVDwvYT4mZ3Q7DQogICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgPGJyPg0KICAg
ICAgPC9kaXY+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgPGRpdj4N
CiAgICAgICAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIGh0dHAt
ZXF1aXY9IkNvbnRlbnQtVHlwZSI+DQogICAgICAgICAgUm9iIC0gdGhhbmtzIGZvciB5b3VyIGNv
bW1lbnRzLCBhbmQganVzdCBhIGZldyBtb3JlIG9mIG1pbmUuDQogICAgICAgICAgSSdsbCB0cnkg
dG8gcmVkdWNlIHRoaW5ncyBkb3duIGEgYml0Ljxicj4NCiAgICAgICAgICA8YnI+DQogICAgICAg
ICAgRmlyc3QsIGl0IGhhcyBvY2N1cnJlZCB0byBtZSB0aGF0LCBwZXJoYXBzIGlyb25pY2FsbHks
IHRoZQ0KICAgICAgICAgICJGdW5jdGlvbmFsIFJlcXVpcmVtZW50cyBmb3IgQXV0aG9yaXR5IERh
dGEiLCBGUkFELCBbMV0gaXMNCiAgICAgICAgICB2ZXJ5IGNsb3NlIHRvIE9BLiBVbmZvcnR1bmF0
ZWx5LCB0aGUgRW5nbGlzaCB2ZXJzaW9uIGlzbid0DQogICAgICAgICAgYXZhaWxhYmxlIG9ubGlu
ZSwgYnV0IGlmIHlvdSBncmFiIG9uZSBvZiB0aGUgb25lcyB3aG9zZQ0KICAgICAgICAgIGxhbmd1
YWdlIHlvdSBjYW4gbWFrZSBvdXQsIGFsbCB0aGF0IHJlYWxseSBtYXR0ZXJzIGlzIEZpZ3VyZSAy
DQogICAgICAgICAgKHAuIDcgaW4gdGhlIEZyZW5jaCB2ZXJzaW9uLCBmb3IgZXhhbXBsZSkuIEl0
J3Mgbm90IGV4YWN0bHkNCiAgICAgICAgICB0aGUgc2FtZSwgYnV0IEkgc2Vuc2UgYSBzaW1pbGFy
aXR5IGluIHRoZSBpbnRlbnQsIGVzcGVjaWFsbHkNCiAgICAgICAgICBpbiB0ZXJtcyBvZiBtYWtp
bmcgY2xlYXIgV0hPIGlzIG1ha2luZyB0aGUgc3RhdGVtZW50LiBGUkFEDQogICAgICAgICAgYWRk
cyBvbmUgbW9yZSB0aGluZywgd2hpY2ggaXMgdW5kZXIgd2hpY2ggcnVsZXMgdGhlIHN0YXRlbWVu
dA0KICAgICAgICAgIGlzIGJlaW5nIG1hZGUuIEkgY291bGQgaW1hZ2luZSwgdGhlcmVmb3JlLCBC
SUJGUkFNRQ0KICAgICAgICAgIGF1dGhvcml0aWVzIGxvb2tpbmcgbXVjaCBsaWtlIE9BIGlmIEZS
QUQgaXMgYWRvcHRlZC48YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAg
ICAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDUvNS8xMyAyOjE3IEFNLCBSb2Jl
cnQNCiAgICAgICAgICAgIFNhbmRlcnNvbiB3cm90ZTo8YnI+DQogICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkNBQmV2c1VIUXQ2RWJGYWpfVEc9UDVNUkVy
a1MyQWhmaE1ncl80Qnh3VmZtcFdabkJDZ0BtYWlsLmdtYWlsLmNvbSIgdHlwZT0iY2l0ZSI+DQog
ICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj48YnI+DQogICAgICAgICAgICAgIDxkaXYgY2xhc3M9
ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+
DQogICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSIiPkFncmVlZCwgaG93ZXZlciB0aGVzZSB3
ZXJlIHNpbXBseSB0bw0KICAgICAgICAgICAgICAgICAgICBkZW1vbnN0cmF0ZSB0aGF0IGFubm90
YXRpb25zIGV4cHJlc3NlZCBpbiBSREYNCiAgICAgICAgICAgICAgICAgICAgcmVxdWlyZSBtb3Jl
IHRoYW4gYSBzaW5nbGUgcmVpZmllZCB0cmlwbGUsIHRvIHJlZnV0ZQ0KICAgICAgICAgICAgICAg
ICAgICB0aGUgY2xhaW0gdGhhdCB3ZSdyZSBzaW1wbHkgcmVpbnZlbnRpbmcgUkRGIGdyYXBocy4N
CiAgICAgICAgICAgICAgICAgICAgw4ImbmJzcDtUaGVyZSBuZWVkcyB0byBiZSBhbiBvbnRvbG9n
eSBhbmQgZGVmaW5lZA0KICAgICAgICAgICAgICAgICAgICBzdHJ1Y3R1cmUuPC9kaXY+DQogICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICBZ
ZXMsIGFuZCB0aGlzIGlzIGJyaW5naW5nIHVwIGZvciBtZSBzb21lIHdvcmsgSSdtIGRvaW5nIGFy
b3VuZA0KICAgICAgICAgIHRoZSBEdWJsaW4gQ29yZSBBcHBsaWNhdGlvbiBQcm9maWxlcyBbMl0u
IEkgbmVlZCB0byBjYXRjaCBzb21lDQogICAgICAgICAgb3RoZXIgZm9sa3MgdG8gaGF2ZSBhIGRp
c2N1c3Npb24gb2YgdGhpcywgYnV0IHdpbGwgZ2V0IGJhY2sgdG8NCiAgICAgICAgICB5b3UgaWYg
YW55dGhpbmcgaW50ZXJlc3RpbmcgYXJpc2VzLg0KICAgICAgICAgIDxibG9ja3F1b3RlIGNpdGU9
Im1pZDpDQUJldnNVSFF0NkViRmFqX1RHPVA1TVJFcmtTMkFoZmhNZ3JfNEJ4d1ZmbXBXWm5CQ2dA
bWFpbC5nbWFpbC5jb20iIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+
DQogICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAg
ICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICA8ZGl2PlllcywgZGVmaW5pdGVseS4gw4ImbmJzcDtUaGUgY2F0YWxv
Z3VpbmcgdHlwZSBvZiB1c2UNCiAgICAgICAgICAgICAgICAgICAgICBjYXNlcyBJIHdvdWxkIHNl
ZSBhcyBjbGVhcmx5IGFubm90YXRpb25zOjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2
Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxk
aXY+KiBSZXZpZXdzIC8gTm90ZXM8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdj4qIFRh
Z2dpbmcgLyBTdWJqZWN0IGNsYXNzaWZpY2F0aW9uPGJyPg0KICAgICAgICAgICAgICAgICAgICA8
L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdj4qIENpdGF0aW9uczwvZGl2Pg0KICAgICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0iIj5Fc3NlbnRp
YWxseSwgd2hlbiB0aGUgaW5mb3JtYXRpb24gaXMNCiAgICAgICAgICAgICAgICAgICAgcHJvdmlk
ZWQgYnkgYSB0aGlyZCBwYXJ0eSwgdGhlbiBpdCB3b3VsZCBiZSBnb29kIHRvDQogICAgICAgICAg
ICAgICAgICAgIGJlIGV4cHJlc3NlZCBhcyBhbiBBbm5vdGF0aW9uIHN1Y2ggdGhhdCB0aGUNCiAg
ICAgICAgICAgICAgICAgICAgcHJvdmVuYW5jZSBpbmZvcm1hdGlvbiBpcyBtYWludGFpbmVkIGFu
ZCBpcw0KICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlIHdpdGggb3RoZXIgc3lzdGVtcyB0
aGF0IHVzZSBPcGVuDQogICAgICAgICAgICAgICAgICAgIEFubm90YXRpb24uPC9kaXY+DQogICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICBJ
J20gc3RpbGwgaGF2aW5nIGEgaGFyZCB0aW1lIHdpdGggdGhlIGRpdmlkaW5nIGxpbmUgYmV0d2Vl
bg0KICAgICAgICAgIHN0dWZmIGFuZCBhbm5vdGF0aW9ucyBvZiBzdHVmZi4gQSByZWNlbnQgYXJ0
aWNsZSBleHBsYWluaW5nDQogICAgICAgICAgdGhlIE9BIGNvbmNlcHQgWzNdIHNhaWQ6PGJyPg0K
ICAgICAgICAgIDxicj4NCiAgICAgICAgICDDgiZuYnNwOyJBbm5vdGF0aW9ucyBkZXNjcmliZSBy
ZXNvdXJjZXMgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLA0KICAgICAgICAgIHdoaWNoIGlz
IHZhbHUtPGJyPg0KICAgICAgICAgIMOCJm5ic3A7w4ImbmJzcDvDgiZuYnNwOyBhYmxlIHRvIG90
aGVyIHVzZXJzLCB3aG8gYXJlIHNlYXJjaGluZyBhbmQgYnJvd3NpbmcNCiAgICAgICAgICByZXNv
dXJjZSBjb2xsZWN0aW9ucy4iPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICBJZiB5b3Ug
aGF2ZSAiYWRkaXRpb25hbCBpbmZvcm1hdGlvbiIgdGhlbiB0aGVyZSBtdXN0IGJlDQogICAgICAg
ICAgIm5vbi1hZGRpdGlvbmFsIGluZm9ybWF0aW9uIiAtLSBhbmQgaWYgeW91IGhhdmUgYSB0aGly
ZCBwYXJ0eQ0KICAgICAgICAgIHRoZW4gdGhlcmUgbXVzdCBiZSBhIGZpcnN0IHBhcnR5ICh0aGUg
c2Vjb25kIHNlZW1zIHRvIGdldA0KICAgICAgICAgIHNraXBwZWQgb3ZlciBpbiB0aGF0IGFuYWxv
Z3kpLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYQ0KICAgICAgICAgIGdlbmVyYWxpemFibGUgcXVl
c3Rpb24gKG9uZSBwZXJzb24ncyAiYWRkaXRpb25hbCIuLi4gZXRjLiksDQogICAgICAgICAgYnV0
IGF0IGxlYXN0IGZvciBhbnkgY29tbXVuaXR5IGxpa2UgbGlicmFyaWVzIHNvbWUgZGVmaW5pdGlv
bg0KICAgICAgICAgIGlzIGdvaW5nIHRvIGJlIG5lZWRlZCBpZiBhbm5vdGF0aW9ucyB3aWxsIGhh
dmUgc29tZQ0KICAgICAgICAgIG9wZXJhdGlvbmFsIG1lYW5pbmcuIFRoYXQncyB3aGF0IEkgdGhp
bmsgaXMgbm90IGNsZWFyICh5ZXQpIGluDQogICAgICAgICAgdGhlIEJJQkZSQU1FIGRvY3VtZW50
LiBJIHN1c3BlY3QgdGhhdCB0aGUgZGl2aXNpb24gaW4gbGlicmFyeQ0KICAgICAgICAgIGRhdGEg
d2lsbCBiZSBiYXNlZCBvbiBwcm92ZW5hbmNlLCBidXQgdGhhdCdzIG5vdCBob3cgQklCRlJBTUUN
CiAgICAgICAgICBkZWZpbmVzIGFubm90YXRpb24uPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAg
ICAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6Q0FCZXZzVUhRdDZFYkZhal9URz1QNU1SRXJrUzJB
aGZoTWdyXzRCeHdWZm1wV1puQkNnQG1haWwuZ21haWwuY29tIiB0eXBlPSJjaXRlIj4NCiAgICAg
ICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9l
eHRyYSI+DQogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxicj4NCiAg
ICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg
ICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSIiPlRoZSBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFr
ZSBpcyB0aGF0DQogICAgICAgICAgICAgICAgICAgIHRoZSBiaWJmcmFtZSBhbm5vdGF0aW9uIG1v
ZGVsIGhhcyBhIHByb3BlcnR5DQogICAgICAgICAgICAgICAgICAgIGJmOmFubm90YXRpb25Cb2R5
TGl0ZXJhbCwgd2hpY2ggaGFzIGEgbGl0ZXJhbCBhcyB0aGUNCiAgICAgICAgICAgICAgICAgICAg
b2JqZWN0LiDDgiZuYnNwO1RoZSBPcGVuIEFubm90YXRpb24gbW9kZWwgZXhwbGljaXRseSBkb2Vz
DQogICAgICAgICAgICAgICAgICAgIG5vdCBhbGxvdyB0aGlzLCBmb3Igc2V2ZXJhbCBpbXBvcnRh
bnQgYW5kIHdlbGwNCiAgICAgICAgICAgICAgICAgICAgZGlzY3Vzc2VkIHJlYXNvbnMuIMOCJm5i
c3A7VGh1cyBhIHBvaW50IHdoZXJlIHRoZSB0d28NCiAgICAgICAgICAgICAgICAgICAgbW9kZWxz
IGFyZSBub3QgY29tcGF0aWJsZS48L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8L2Jsb2NrcXVv
dGU+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIFJpZ2h0LiBCdXQgdGhlbiBhZ2FpbiwgREMg
dHlwZXMgZG9lc24ndCBpbmNsdWRlICJsaXRlcmFsIiBhcyBhDQogICAgICAgICAgdHlwZS4gVGhl
IHdob2xlIHR5cGluZyB0aGluZyBpcyBzb21ldGhpbmcgSSB3b3VsZCBuZWVkIHRvDQogICAgICAg
ICAgdGhpbmsgYWJvdXQgbW9yZS4gSWYgeW91ciBvbmx5IGludGVyZXN0IGlzIGxpdGVyYWwgdi4g
VVJJLA0KICAgICAgICAgIHRoZW4gdGhlIEJJQkZSQU1FIGNob2ljZSBpcyBmaW5lLiBJZiB5b3Ug
aGF2ZSBhIHZpZGVvIG9yIHNvdW5kDQogICAgICAgICAgZmlsZSwgdGhhdCB3b3VsZCBiZSBhIFVS
SS4gU29tZXRoaW5nIHRoYXQgaXMgaW50ZXJlc3RpbmcgaW4NCiAgICAgICAgICB0aGUgT0EgbW9k
ZWwgaXMgdGhhdCBpdCBhbGxvd3MgeW91IHRvIG1ha2Ugc3RhdGVtZW50cyBhYm91dA0KICAgICAg
ICAgIHRoZSB0aGluZyB0aGUgVVJJIHBvaW50cyB0byBbZS5nLiBhbm5vdGF0aW5nIGEgcGFydGlj
dWxhcg0KICAgICAgICAgIGNvb3JkaW5hdGUgYXJlYSBvbiBhIG1hcF0uIEkgaGFkbid0IHRob3Vn
aHQgYWJvdXQgdGhhdCwgYW5kDQogICAgICAgICAgbm93IHdpbGwgaGF2ZSB0byBnbyBiYWNrIHRv
IHRoZSBPQSBkb2N1bWVudCBhbmQgc2VlIHdoZXJlIHRoYXQNCiAgICAgICAgICBmaXRzIGluLiBU
aGlzIGlzIG9uZSBvZiB0aG9zZSBhcmVhcyB3aGVyZSB0aGUgIm1ldGEiIGFzcGVjdCBvZg0KICAg
ICAgICAgIGxpYnJhcnkgZGF0YSBoYXMgYW4gYWZmZWN0LiBNdXN0IHRoaW5rIG1vcmUuLi4uLjxi
cj4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkNBQmV2
c1VIUXQ2RWJGYWpfVEc9UDVNUkVya1MyQWhmaE1ncl80Qnh3VmZtcFdabkJDZ0BtYWlsLmdtYWls
LmNvbSIgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAg
ICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgIDxkaXYgY2xh
c3M9ImdtYWlsX3F1b3RlIj48YnI+DQogICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9
ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgNCiAgICAgICAgICAgICAgICAgICAg
MHB4DQowLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIw
NCwyMDQsMjA0KTtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAg
ICAgICAgICAgICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4g
Tm90ZSB0aGF0DQogICAgICAgICAgICAgICAgICAgICAgdGhlcmUgaXMgbm90aGluZyBhYm91dCBs
aWJyYXJ5IGRhdGEgdGhhdCB3b3VsZA0KICAgICAgICAgICAgICAgICAgICAgIHByZXZlbnQgYW55
b25lIGZyb20gYXBwbHlpbmcgYW4gT3BlbiBBbm5vdGF0aW9uIHRvDQogICAgICAgICAgICAgICAg
ICAgICAgdGhlIGRhdGEuIFRoZSBxdWVzdGlvbiBpcywgZG8gd2Ugd2FudCB0aGlzIHRvIGJlDQog
ICAgICAgICAgICAgICAgICAgICAgdGhlIG9ubHkgd2F5IHRvLCBmb3IgZXhhbXBsZSwgYXNzaWdu
IGEgc3ViamVjdA0KICAgICAgICAgICAgICAgICAgICAgIGhlYWRpbmcgdG8gYSBXb3JrPyBPckkg
d291bGRuJ3QgYXNzdW1lIHRoYXQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgQklCRlJBTUUg
ZGF0YSB3aWxsIGV4aXN0ICphcyBpcyogaW4gdGhlIG9wZW4NCiAgICAgICAgICAgICAgICAgICAg
ICB3b3JsZC4gPC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAg
ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgPGRpdiBzdHlsZT0iIj5UaGVuIEkgd291bGQgc2VyaW91c2x5IHF1ZXN0aW9uIHdo
eSBSREYNCiAgICAgICAgICAgICAgICAgICAgaXMgYmVpbmcgdXNlZCBhdCBhbGwuPC9kaXY+DQog
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDxicj4NCiAgICAgICAg
ICBJIHNlZSB0aGlzIGRpZmZlcmVudGx5LCBwZXJoYXBzIGJlY2F1c2Ugb2YgbXkgd29yayBvbg0K
ICAgICAgICAgIEFwcGxpY2F0aW9uIFByb2ZpbGVzLiBJIHRoaW5rIHRoYXQgbWFueSBjb21tdW5p
dGllcyB3aWxsIGhhdmUNCiAgICAgICAgICBhbiBpbnRlcm5hbCB2aWV3IG9mIHRoZWlyIGRhdGEs
IGFuZCBhbm90aGVyICJmYWNlIiB0aGF0IHRoZXkNCiAgICAgICAgICBwcmVzZW50IHRvIHRoZSBv
cGVuIHdvcmxkLiBUaGUgYmFzaWMgc3RydWN0dXJlIG9mIFJERiwgdGhhdA0KICAgICAgICAgIGlz
LCB0cmlwbGVzLCBhbmQgdGhlIHVzZSBvZiBkZWZpbmVkIG9udG9sb2dpZXMsIGlzIGEgZ29vZCB3
YXkNCiAgICAgICAgICB0byBvcmdhbml6ZSBkYXRhIHdoZXRoZXIgaXQgaXMgb3BlbiBvciBub3Qu
IEluIGZhY3QsIHRoZXJlIGFyZQ0KICAgICAgICAgIGVudGVycHJpc2UgdXNlcyBvZiBsaW5rZWQg
ZGF0YS4gTW9kZWxpbmcgeW91ciBlbnRlcnByaXNlIGRhdGENCiAgICAgICAgICBvbiBSREYgbWFr
ZXMgaXQgbXVjaCBtb3JlIGxpa2VseSB0aGF0IHlvdSB3aWxsIGJlIGFibGUgdG8NCiAgICAgICAg
ICBleHRyYWN0IGEgcHVibGljIHZpZXcuIEluIHRoZSBEdWJsaW4gQ29yZSBhcmVuYSB3ZSBhcmUg
bG9va2luZw0KICAgICAgICAgIGF0IEFwcGxpY2F0aW9uIFByb2ZpbGVzIGFzIGEgd2F5IHRvIGFk
ZCB0aGUgY29uc3RyYWludHMgdGhhdA0KICAgICAgICAgIGFyZSBuZWVkZWQgd2l0aGluIGEgY29t
bXVuaXR5IG9yIGVudGVycHJpc2UgdGhhdCBoYXMgc29tZQ0KICAgICAgICAgIG5vbi1vcGVuIG5l
ZWRzLCB3aGlsZSBlYXNpbHkgYWxsb3dpbmcgdGhlIGRlcml2YXRpb24gb2YgYW4NCiAgICAgICAg
ICBvcGVuIHZpZXcuPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YmxvY2txdW90ZSBj
aXRlPSJtaWQ6Q0FCZXZzVUhRdDZFYkZhal9URz1QNU1SRXJrUzJBaGZoTWdyXzRCeHdWZm1wV1pu
QkNnQG1haWwuZ21haWwuY29tIiB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgIDxkaXYgZGlyPSJs
dHIiPg0KICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAg
ICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgPGRpdj7D
giZuYnNwOzwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0iIj5XYXMgdGhlIGNo
b2ljZSBvZiBhbm5vdGF0aW9uIGFzIGEgbW9kZWwNCiAgICAgICAgICAgICAgICAgICAgZGlzY3Vz
c2VkIG9uIHRoaXMgbGlzdCAoYW5kIGhlbmNlIGF2YWlsYWJsZSBpbiB0aGUNCiAgICAgICAgICAg
ICAgICAgICAgYXJjaGl2ZXMpIG9yIHdhcyBpdCBzaW1wbHkgcHJlc2VudGVkIGZhaXQgYWNjb21w
bGk/PC9kaXY+DQogICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvZGl2Pg0K
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDxi
cj4NCiAgICAgICAgICBSb2IsIHdoYXQgeW91IGFuZCBJIGFyZSBkb2luZyBoZXJlIGlzIHRoZSBm
dWxsIGV4dGVudCBvZiBvdXINCiAgICAgICAgICBhYmlsaXR5IHRvIGludGVyYWN0IGluIHRoZSBC
SUJGUkFNRSBwcm9jZXNzLiBJZiB5b3UgbG9vayBhdA0KICAgICAgICAgIHRoZSAiQ29udHJpYnV0
ZSIgcGFnZSBbNF0gb2YgQklCRlJBTUUgeW91IHdpbGwgc2VlIHRoYXQgdGhlDQogICAgICAgICAg
b25seSBpbnZvbHZlbWVudCBmb3IgdGhlIGNvbW11bml0eSBpbiB0aGUgQklCRlJBTUUgZGV2ZWxv
cG1lbnQNCiAgICAgICAgICBpcyBkaXNjdXNzaW9uIG9uIHRoaXMgbGlzdC4gRGlzY3Vzc2lvbiB0
aGF0LCBsaWtlIHRoaXMgdGhyZWFkLA0KICAgICAgICAgIHRha2VzIHBsYWNlIGdlbmVyYWxseSBi
ZXR3ZWVuIGxpc3QgbWVtYmVycyB3aXRoIG5vIGRpcmVjdA0KICAgICAgICAgIGludm9sdmVtZW50
IGluIEJJQkZSQU1FIGRldmVsb3BtZW50LiBJIHdvdWxkIGhhdmUgc2ltcGx5DQogICAgICAgICAg
cmVwbGllZCB0byB5b3UgaW5kaXZpZHVhbGx5LCBidXQgSSdtIG9mIHRoZSBtaW5kIHRoYXQgYSBm
ZXcNCiAgICAgICAgICByZWFkZXJzIG9uIHRoZSBsaXN0IG1pZ2h0IGZpbmQgb3VyIG11c2luZ3Mg
aW50ZXJlc3RpbmcuIEluDQogICAgICAgICAgdGVybXMgb2YgaGF2aW5nIGFueSBpbmZsdWVuY2Ug
b3ZlciB0aGUgZGV2ZWxvcG1lbnQgb2YNCiAgICAgICAgICBCSUJGUkFNRSwgSSBoYXZlIG5vIHN1
Y2ggY29uY2VpdC48YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIGtjPGJyPg0KICAgICAg
ICAgIDxicj4NCiAgICAgICAgICBbMV0NCiAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRy
dWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuaWZsYS5v
cmcvcHVibGljYXRpb25zL2Z1bmN0aW9uYWwtcmVxdWlyZW1lbnRzLWZvci1hdXRob3JpdHktZGF0
YSI+aHR0cDovL3d3dy5pZmxhLm9yZy9wdWJsaWNhdGlvbnMvZnVuY3Rpb25hbC1yZXF1aXJlbWVu
dHMtZm9yLWF1dGhvcml0eS1kYXRhPC9hPjxicj4NCiAgICAgICAgICBbMl0gPGEgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8v
ZHVibGluY29yZS5vcmcvZG9jdW1lbnRzL2RjLWRzcC8iPmh0dHA6Ly9kdWJsaW5jb3JlLm9yZy9k
b2N1bWVudHMvZGMtZHNwLzwvYT48YnI+DQogICAgICAgICAgWzNdDQogICAgICAgICAgPGEgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo
dHRwOi8vd3d3LnNwcmluZ2VyLmNvbS9jb21wdXRlci9pbmZvcm1hdGlvbitzeXN0ZW1zK2FuZCth
cHBsaWNhdGlvbnMvam91cm5hbC8xMTA0MiI+aHR0cDovL3d3dy5zcHJpbmdlci5jb20vY29tcHV0
ZXIvaW5mb3JtYXRpb24rc3lzdGVtcythbmQrYXBwbGljYXRpb25zL2pvdXJuYWwvMTEwNDI8L2E+
PGJyPg0KICAgICAgICAgIFs0XSA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3ot
dHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly9iaWJmcmFtZS5vcmcvY29udHJpYnV0ZS8i
Pmh0dHA6Ly9iaWJmcmFtZS5vcmcvY29udHJpYnV0ZS88L2E+PGJyPg0KICAgICAgICAgIDxwcmUg
Y2xhc3M9Im1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSANCkthcmVuIENveWxlDQo8YSBtb3ot
ZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9
Im1haWx0bzprY295bGVAa2NveWxlLm5ldCI+a2NveWxlQGtjb3lsZS5uZXQ8L2E+IDxhIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0
cDovL2tjb3lsZS5uZXQiPmh0dHA6Ly9rY295bGUubmV0PC9hPg0KcGg6IDEtNTEwLTU0MC03NTk2
DQptOiAxLTUxMC00MzUtODIzNA0Kc2t5cGU6IGtjb3lsZW5ldDwvcHJlPg0KICAgICAgICA8L2Rp
dj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAg
IDxwcmUgY2xhc3M9Im1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSANCkthcmVuIENveWxlDQo8
YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86a2NveWxlQGtj
b3lsZS5uZXQiPmtjb3lsZUBrY295bGUubmV0PC9hPiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZy
ZWV0ZXh0IiBocmVmPSJodHRwOi8va2NveWxlLm5ldCI+aHR0cDovL2tjb3lsZS5uZXQ8L2E+DQpw
aDogMS01MTAtNTQwLTc1OTYNCm06IDEtNTEwLTQzNS04MjM0DQpza3lwZToga2NveWxlbmV0PC9w
cmU+DQogIA0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4=

--Apple-Mail-576F2FAD-2EE0-4BE2-A604-D395CE5DD5B2--

------------------------------

Date:    Sun, 5 May 2013 10:37:37 -0700
From:    Karen Coyle <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

On 5/5/13 9:21 AM, Cole, Timothy W wrote:
> Karen-
>
> I empathize with your text, "I'm still having a hard time with the divi=
ding line between stuff and annotations of stuff."
>
> 4 years ago at the outset of the Open Annotation Collaboration, I start=
ed out thinking that there was need for bright (or at least a fuzzy-brigh=
t) line there.
Hi, Tim. Thanks. I totally agree that we aren't going to have a bright=20
line. I am wondering about the BIBFRAME view, though. Two things in that =

regard:

1) The library world, with its penchant for standards and its need for=20
sharing, will need to make some decisions in this area. This is where I=20
think that Application Profiles (or Community Profiles) could come in -- =

to allow different communities to describe, to themselves and others,=20
their view of "stuff v. annotations of stuff." I see it more as "by way=20
of explanation" than hard and fast rules. It should help re-use of the da=
ta.

2) To me this points out what I see as a flaw in current library=20
practice, which I'm hoping to explain in an upcoming Library Journal=20
column (if I can make sense of what I am thinking): that libraries stop=20
abruptly at metadata and do not go on to include actual "stuff" as part=20
of their mission. I'm not talking about preserving and archiving here -- =

I mean *use*. The OA model is a kind of use. Visualization of data=20
(stats, etc.) is another kind of use. With the famed four user tasks of=20
FRBR, libraries wash their hands of the information world at "Obtain".=20
We operate in a meta-verse apart from any information resources that are =

not our own metadata about our resources. This, in a sense, is the crux=20
of the annotation problem for libraries -- we only recognize a very=20
narrow view of annotation because we have such a narrow view of=20
resources. (Admittedly, off-line resources must still be represented as=20
"elsewhere" beyond the metadata, but honestly, we should be doing more=20
with online stuff.)

All in all, for me this has been a very productive discussion, and I=20
thank you all. To me it goes to the heart of the library's distance from =

the modern world of information.

Or maybe I'm just particularly susceptible to idle brain waves this=20
Sunday morning.

kc


>   However, I'm not sure now that there is.  Being able to work with ann=
otations sometimes as annotations of stuff and sometimes as stuff in thei=
r own right is proving a very powerful approach in practice. The evolutio=
n of the Open Annotation data model has been heavily influenced by experi=
mentation, including some experimentation at Illinois (and elsewhere) wit=
h annotation of library resources (including authorities) and bibliograph=
ic information derived from MARC and from other sources. I've been struck=
 how not useful maintaining an unequivocal distinction between annotation=
s of stuff and stuff turns out to be in practice. A bit like the question=
 in physics about whether light is a wave or a particle. It depends.
>
> I also should say that our experimental experience over the last few ye=
ars has heavily influenced a number of decisions intrinsic to the current=
 Open Annotation data model, including the decisions about not including =
a 'hasLiteralBody' predicate and not trying to express the motivation of =
an annotation through sub-classing (myself and other librarians here at I=
llinois were on the other side of this issue for quite a while, but came =
around in light of our own experimentation showing that this just did not=
 work well in practice). At Illinois we're now moving forward this summer=
 on a brand new project within the HathTrust Research Center that will ma=
ke extensive use of annotations conforming to the Open Annotation model, =
both in the curation of the bibliographic records and authorities and is =
the curation of the full text. We'll learn more, I'm sure, but it's defin=
itely the right way for us to be going right now.
>
> While I take your earlier point that BIBFRAME's is coming at annotation=
 from its own unique perspective, I do think there is overlap with the us=
e cases encompassed by Open Annotation, and I anticipate that some of the=
 experimentation and testing done leading up to the Open Annotation data =
model might resonate with some of the BIBFRAME annotation use cases (thou=
gh of course I understand that in other instances it might not).
>
> Thanks,
>
> Tim Cole
> University of Illinois at UC.
>
>
> ________________________________________
> From: Bibliographic Framework Transition Initiative Forum [BIBFRAME@LIS=
TSERV.LOC.GOV] on behalf of Karen Coyle [[log in to unmask]]
> Sent: Sunday, May 05, 2013 10:26
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Annotations (Was: Documents and improvements)
>
> Jeff, I'm thinking about the part of FRAD that is outside of the main b=
ox (which I think may be handled by SKOS). There are some structures that=
 modify (or, annotate) the authority data:
>
> First, there is a "box" with:
>   - name
>   - identifier
>
> Both of these are SKOS-able, I believe.
>
> That "box" itself is modified with:
>    - Access point
>    -- Rules (for access point)
>    --- Agency (that applied the rules)
>
> It is this last part that looks OA-ish to me. This goes beyond what you=
 have in VIAF, which contains an identifier for the original source, but =
doesn't separate access points from identities (as far as I can tell), an=
d doesn't include rules. The Agency covered by the source URI is implied,=
 but if you have something like NACO you may want the actual agency that =
made the decision (040 $a or something like that).
>
> kc
>
>
>
> On 5/5/13 8:05 AM, Young,Jeff (OR) wrote:
> Or SKOS for that matter...
>
> Sent from my iPad
>
> On May 5, 2013, at 11:03 AM, "Karen Coyle" <[log in to unmask]<mailto:lis=
[log in to unmask]>> wrote:
>
> Rob - thanks for your comments, and just a few more of mine. I'll try t=
o reduce things down a bit.
>
> First, it has occurred to me that, perhaps ironically, the "Functional =
Requirements for Authority Data", FRAD, [1] is very close to OA. Unfortun=
ately, the English version isn't available online, but if you grab one of=
 the ones whose language you can make out, all that really matters is Fig=
ure 2 (p. 7 in the French version, for example). It's not exactly the sam=
e, but I sense a similarity in the intent, especially in terms of making =
clear WHO is making the statement. FRAD adds one more thing, which is und=
er which rules the statement is being made. I could imagine, therefore, B=
IBFRAME authorities looking much like OA if FRAD is adopted.
>
>
> On 5/5/13 2:17 AM, Robert Sanderson wrote:
>
> Agreed, however these were simply to demonstrate that annotations expre=
ssed in RDF require more than a single reified triple, to refute the clai=
m that we're simply reinventing RDF graphs.  There needs to be an ontolog=
y and defined structure.
>
> Yes, and this is bringing up for me some work I'm doing around the Dubl=
in Core Application Profiles [2]. I need to catch some other folks to hav=
e a discussion of this, but will get back to you if anything interesting =
arises.
> Yes, definitely.  The cataloguing type of use cases I would see as clea=
rly annotations:
>
> * Reviews / Notes
> * Tagging / Subject classification
> * Citations
>
> Essentially, when the information is provided by a third party, then it=
 would be good to be expressed as an Annotation such that the provenance =
information is maintained and is compatible with other systems that use O=
pen Annotation.
>
> I'm still having a hard time with the dividing line between stuff and a=
nnotations of stuff. A recent article explaining the OA concept [3] said:=

>
>   "Annotations describe resources with additional information, which is=
 valu-
>      able to other users, who are searching and browsing resource colle=
ctions."
>
> If you have "additional information" then there must be "non-additional=
 information" -- and if you have a third party then there must be a first=
 party (the second seems to get skipped over in that analogy). I don't th=
ink this is a generalizable question (one person's "additional"... etc.),=
 but at least for any community like libraries some definition is going t=
o be needed if annotations will have some operational meaning. That's wha=
t I think is not clear (yet) in the BIBFRAME document. I suspect that the=
 division in library data will be based on provenance, but that's not how=
 BIBFRAME defines annotation.
>
>
>
> The point I was trying to make is that the bibframe annotation model ha=
s a property bf:annotationBodyLiteral, which has a literal as the object.=
  The Open Annotation model explicitly does not allow this, for several i=
mportant and well discussed reasons.  Thus a point where the two models a=
re not compatible.
>
> Right. But then again, DC types doesn't include "literal" as a type. Th=
e whole typing thing is something I would need to think about more. If yo=
ur only interest is literal v. URI, then the BIBFRAME choice is fine. If =
you have a video or sound file, that would be a URI. Something that is in=
teresting in the OA model is that it allows you to make statements about =
the thing the URI points to [e.g. annotating a particular coordinate area=
 on a map]. I hadn't thought about that, and now will have to go back to =
the OA document and see where that fits in. This is one of those areas wh=
ere the "meta" aspect of library data has an affect. Must think more.....=

>
>
>
> Note that there is nothing about library data that would prevent anyone=
 from applying an Open Annotation to the data. The question is, do we wan=
t this to be the only way to, for example, assign a subject heading to a =
Work? OrI wouldn't assume that the BIBFRAME data will exist *as is* in th=
e open world.
>
> Then I would seriously question why RDF is being used at all.
>
> I see this differently, perhaps because of my work on Application Profi=
les. I think that many communities will have an internal view of their da=
ta, and another "face" that they present to the open world. The basic str=
ucture of RDF, that is, triples, and the use of defined ontologies, is a =
good way to organize data whether it is open or not. In fact, there are e=
nterprise uses of linked data. Modeling your enterprise data on RDF makes=
 it much more likely that you will be able to extract a public view. In t=
he Dublin Core arena we are looking at Application Profiles as a way to a=
dd the constraints that are needed within a community or enterprise that =
has some non-open needs, while easily allowing the derivation of an open =
view.
>
>
> Was the choice of annotation as a model discussed on this list (and hen=
ce available in the archives) or was it simply presented fait accompli?
>
> Rob, what you and I are doing here is the full extent of our ability to=
 interact in the BIBFRAME process. If you look at the "Contribute" page [=
4] of BIBFRAME you will see that the only involvement for the community i=
n the BIBFRAME development is discussion on this list. Discussion that, l=
ike this thread, takes place generally between list members with no direc=
t involvement in BIBFRAME development. I would have simply replied to you=
 individually, but I'm of the mind that a few readers on the list might f=
ind our musings interesting. In terms of having any influence over the de=
velopment of BIBFRAME, I have no such conceit.
>
> kc
>
> [1] http://www.ifla.org/publications/functional-requirements-for-author=
ity-data
> [2] http://dublincore.org/documents/dc-dsp/
> [3] http://www.springer.com/computer/information+systems+and+applicatio=
ns/journal/11042
> [4] http://bibframe.org/contribute/
>
> --
> Karen Coyle
> [log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>
> --
> Karen Coyle
> [log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

--=20
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

------------------------------

Date:    Sun, 5 May 2013 19:43:41 +0000
From:    "Cole, Timothy W" <[log in to unmask]>
Subject: Re: Annotations (Was: Documents and improvements)

Thanks, Karen, for reply....
________________________________________
From: Karen Coyle [[log in to unmask]]
Sent: Sunday, May 05, 2013 12:37
To: Bibliographic Framework Transition Initiative Forum
Cc: Cole, Timothy W
Subject: Re: [BIBFRAME] Annotations (Was: Documents and improvements)

On 5/5/13 9:21 AM, Cole, Timothy W wrote:
> Karen-
>
> I empathize with your text, "I'm still having a hard time with the dividi=
ng line between stuff and annotations of stuff."
>
> 4 years ago at the outset of the Open Annotation Collaboration, I started=
 out thinking that there was need for bright (or at least a fuzzy-bright) l=
ine there.
Hi, Tim. Thanks. I totally agree that we aren't going to have a bright
line. I am wondering about the BIBFRAME view, though. Two things in that
regard:

1) The library world, with its penchant for standards and its need for
sharing, will need to make some decisions in this area. This is where I
think that Application Profiles (or Community Profiles) could come in --
to allow different communities to describe, to themselves and others,
their view of "stuff v. annotations of stuff." I see it more as "by way
of explanation" than hard and fast rules. It should help re-use of the data=
.

twc: I think this is a reasonable strategy.

2) To me this points out what I see as a flaw in current library
practice, which I'm hoping to explain in an upcoming Library Journal
column (if I can make sense of what I am thinking): that libraries stop
abruptly at metadata and do not go on to include actual "stuff" as part
of their mission.

twc: strong agreement on this point, for me at least. =20

 I'm not talking about preserving and archiving here --
I mean *use*. The OA model is a kind of use. Visualization of data
(stats, etc.) is another kind of use. With the famed four user tasks of
FRBR, libraries wash their hands of the information world at "Obtain".
We operate in a meta-verse apart from any information resources that are
not our own metadata about our resources. This, in a sense, is the crux
of the annotation problem for libraries -- we only recognize a very
narrow view of annotation because we have such a narrow view of
resources. (Admittedly, off-line resources must still be represented as
"elsewhere" beyond the metadata, but honestly, we should be doing more
with online stuff.)

twc: Agreed. And just to be clear (which I perhaps wasn't in my earlier pos=
t), I am not trying to denigrate the value of distinguishing (for example) =
between Tim Cole the person and Tim Cole's Home Page, nor otherwise start a=
 big discussion as to what you get when you de-reference URIs (if it's an H=
TTP URI for an annotation, the Open Annotation model says you get back "a r=
epresentation of the Annotation ... in an appropriate graph serialization f=
ormat."). I only wanted to suggest that generically annotations can have a =
lot in common with other sub-classes of resources, e.g., they may contain u=
seful information, may themselves be targets of annotation, etc. -- which a=
mong other things says (for example) that metadata can be annotated as well=
 as full text and to the extent that annotations of full-text are treated a=
s a form of metadata for that full-text, these annotations-as-metadata can =
still usefully be the target of subsequent annotation, and so on. A broad u=
nderstanding of metadata. In other words, libraries need to do a better job=
 recognizing that annotations (and metadata generally) are content too.

All in all, for me this has been a very productive discussion, and I
thank you all. To me it goes to the heart of the library's distance from
the modern world of information.

Or maybe I'm just particularly susceptible to idle brain waves this
Sunday morning.

twc: For me it's Sunday AND I've been travelling, so apologies in advance i=
f not making sense.

kc


>   However, I'm not sure now that there is.  Being able to work with annot=
ations sometimes as annotations of stuff and sometimes as stuff in their ow=
n right is proving a very powerful approach in practice. The evolution of t=
he Open Annotation data model has been heavily influenced by experimentatio=
n, including some experimentation at Illinois (and elsewhere) with annotati=
on of library resources (including authorities) and bibliographic informati=
on derived from MARC and from other sources. I've been struck how not usefu=
l maintaining an unequivocal distinction between annotations of stuff and s=
tuff turns out to be in practice. A bit like the question in physics about =
whether light is a wave or a particle. It depends.
>
> I also should say that our experimental experience over the last few year=
s has heavily influenced a number of decisions intrinsic to the current Ope=
n Annotation data model, including the decisions about not including a 'has=
LiteralBody' predicate and not trying to express the motivation of an annot=
ation through sub-classing (myself and other librarians here at Illinois we=
re on the other side of this issue for quite a while, but came around in li=
ght of our own experimentation showing that this just did not work well in =
practice). At Illinois we're now moving forward this summer on a brand new =
project within the HathTrust Research Center that will make extensive use o=
f annotations conforming to the Open Annotation model, both in the curation=
 of the bibliographic records and authorities and is the curation of the fu=
ll text. We'll learn more, I'm sure, but it's definitely the right way for =
us to be going right now.
>
> While I take your earlier point that BIBFRAME's is coming at annotation f=
rom its own unique perspective, I do think there is overlap with the use ca=
ses encompassed by Open Annotation, and I anticipate that some of the exper=
imentation and testing done leading up to the Open Annotation data model mi=
ght resonate with some of the BIBFRAME annotation use cases (though of cour=
se I understand that in other instances it might not).
>
> Thanks,
>
> Tim Cole
> University of Illinois at UC.
>
>
> ________________________________________
> From: Bibliographic Framework Transition Initiative Forum [BIBFRAME@LISTS=
ERV.LOC.GOV] on behalf of Karen Coyle [[log in to unmask]]
> Sent: Sunday, May 05, 2013 10:26
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Annotations (Was: Documents and improvements)
>
> Jeff, I'm thinking about the part of FRAD that is outside of the main box=
 (which I think may be handled by SKOS). There are some structures that mod=
ify (or, annotate) the authority data:
>
> First, there is a "box" with:
>   - name
>   - identifier
>
> Both of these are SKOS-able, I believe.
>
> That "box" itself is modified with:
>    - Access point
>    -- Rules (for access point)
>    --- Agency (that applied the rules)
>
> It is this last part that looks OA-ish to me. This goes beyond what you h=
ave in VIAF, which contains an identifier for the original source, but does=
n't separate access points from identities (as far as I can tell), and does=
n't include rules. The Agency covered by the source URI is implied, but if =
you have something like NACO you may want the actual agency that made the d=
ecision (040 $a or something like that).
>
> kc
>
>
>
> On 5/5/13 8:05 AM, Young,Jeff (OR) wrote:
> Or SKOS for that matter...
>
> Sent from my iPad
>
> On May 5, 2013, at 11:03 AM, "Karen Coyle" <[log in to unmask]<mailto:lists=
@KCOYLE.NET>> wrote:
>
> Rob - thanks for your comments, and just a few more of mine. I'll try to =
reduce things down a bit.
>
> First, it has occurred to me that, perhaps ironically, the "Functional Re=
quirements for Authority Data", FRAD, [1] is very close to OA. Unfortunatel=
y, the English version isn't available online, but if you grab one of the o=
nes whose language you can make out, all that really matters is Figure 2 (p=
. 7 in the French version, for example). It's not exactly the same, but I s=
ense a similarity in the intent, especially in terms of making clear WHO is=
 making the statement. FRAD adds one more thing, which is under which rules=
 the statement is being made. I could imagine, therefore, BIBFRAME authorit=
ies looking much like OA if FRAD is adopted.
>
>
> On 5/5/13 2:17 AM, Robert Sanderson wrote:
>
> Agreed, however these were simply to demonstrate that annotations express=
ed in RDF require more than a single reified triple, to refute the claim th=
at we're simply reinventing RDF graphs.  There needs to be an ontology and =
defined structure.
>
> Yes, and this is bringing up for me some work I'm doing around the Dublin=
 Core Application Profiles [2]. I need to catch some other folks to have a =
discussion of this, but will get back to you if anything interesting arises=
.
> Yes, definitely.  The cataloguing type of use cases I would see as clearl=
y annotations:
>
> * Reviews / Notes
> * Tagging / Subject classification
> * Citations
>
> Essentially, when the information is provided by a third party, then it w=
ould be good to be expressed as an Annotation such that the provenance info=
rmation is maintained and is compatible with other systems that use Open An=
notation.
>
> I'm still having a hard time with the dividing line between stuff and ann=
otations of stuff. A recent article explaining the OA concept [3] said:
>
>   "Annotations describe resources with additional information, which is v=
alu-
>      able to other users, who are searching and browsing resource collect=
ions."
>
> If you have "additional information" then there must be "non-additional i=
nformation" -- and if you have a third party then there must be a first par=
ty (the second seems to get skipped over in that analogy). I don't think th=
is is a generalizable question (one person's "additional"... etc.), but at =
least for any community like libraries some definition is going to be neede=
d if annotations will have some operational meaning. That's what I think is=
 not clear (yet) in the BIBFRAME document. I suspect that the division in l=
ibrary data will be based on provenance, but that's not how BIBFRAME define=
s annotation.
>
>
>
> The point I was trying to make is that the bibframe annotation model has =
a property bf:annotationBodyLiteral, which has a literal as the object.  Th=
e Open Annotation model explicitly does not allow this, for several importa=
nt and well discussed reasons.  Thus a point where the two models are not c=
ompatible.
>
> Right. But then again, DC types doesn't include "literal" as a type. The =
whole typing thing is something I would need to think about more. If your o=
nly interest is literal v. URI, then the BIBFRAME choice is fine. If you ha=
ve a video or sound file, that would be a URI. Something that is interestin=
g in the OA model is that it allows you to make statements about the thing =
the URI points to [e.g. annotating a particular coordinate area on a map]. =
I hadn't thought about that, and now will have to go back to the OA documen=
t and see where that fits in. This is one of those areas where the "meta" a=
spect of library data has an affect. Must think more.....
>
>
>
> Note that there is nothing about library data that would prevent anyone f=
rom applying an Open Annotation to the data. The question is, do we want th=
is to be the only way to, for example, assign a subject heading to a Work? =
OrI wouldn't assume that the BIBFRAME data will exist *as is* in the open w=
orld.
>
> Then I would seriously question why RDF is being used at all.
>
> I see this differently, perhaps because of my work on Application Profile=
s. I think that many communities will have an internal view of their data, =
and another "face" that they present to the open world. The basic structure=
 of RDF, that is, triples, and the use of defined ontologies, is a good way=
 to organize data whether it is open or not. In fact, there are enterprise =
uses of linked data. Modeling your enterprise data on RDF makes it much mor=
e likely that you will be able to extract a public view. In the Dublin Core=
 arena we are looking at Application Profiles as a way to add the constrain=
ts that are needed within a community or enterprise that has some non-open =
needs, while easily allowing the derivation of an open view.
>
>
> Was the choice of annotation as a model discussed on this list (and hence=
 available in the archives) or was it simply presented fait accompli?
>
> Rob, what you and I are doing here is the full extent of our ability to i=
nteract in the BIBFRAME process. If you look at the "Contribute" page [4] o=
f BIBFRAME you will see that the only involvement for the community in the =
BIBFRAME development is discussion on this list. Discussion that, like this=
 thread, takes place generally between list members with no direct involvem=
ent in BIBFRAME development. I would have simply replied to you individuall=
y, but I'm of the mind that a few readers on the list might find our musing=
s interesting. In terms of having any influence over the development of BIB=
FRAME, I have no such conceit.
>
> kc
>
> [1] http://www.ifla.org/publications/functional-requirements-for-authorit=
y-data
> [2] http://dublincore.org/documents/dc-dsp/
> [3] http://www.springer.com/computer/information+systems+and+applications=
/journal/11042
> [4] http://bibframe.org/contribute/
>
> --
> Karen Coyle
> [log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>
> --
> Karen Coyle
> [log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

------------------------------

End of BIBFRAME Digest - 4 May 2013 to 5 May 2013 (#2013-68)
************************************************************

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager