<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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;}
span.EmailStyle17
{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.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi Mark<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks for moderating the discussions. This is a long email and you have another one that may need discussing as well.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In this response I have mainly tried interpreting some of the cases you mention in valid VO-UML diagrams. PNGs of the diagrams are attached and comments are
added to the text below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> dm-bounces@ivoa.net [mailto:dm-bounces@ivoa.net]
<b>On Behalf Of </b>CresitelloDittmar, Mark<br>
<b>Sent:</b> Tuesday, December 29, 2015 12:57 PM<br>
<b>To:</b> Data Models mailing list <dm@ivoa.net><br>
<b>Subject:</b> [vodml] Attribute multiplicity<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">All,<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
I am attempting to spawn this thread out of the 'vo-dml for cube' subject which has expanded into multiple inter-related topics.<br>
<a href="http://mail.ivoa.net/pipermail/dm/2015-December/005271.html">http://mail.ivoa.net/pipermail/dm/2015-December/005271.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">The request is that the vo-dml specification be modified to allow a variable multiplicity in Attributes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">The current document (Oct 2015) states in Section 4.14: Attribute<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
"The multiplicity of Attributes is restricted to be either 0..1, or n..n where n is a positive integer literal. i.e. open ended collections are not allowed, nor is 0..n, with n>1."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> and in Section 4.19: Multiplicity<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
"A special case is the assignment of a Multiplicity to an Attribute. The only combinations of minOccurs..maxOccurs that are allowed on attribute definitions are 0..1, 1..1 (or simply 1), and n..n (or simply n) with n>1. i.e. for multiplicity greater than
1 the attribute can be interpreted as an array of fixed size."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
Gerard explains the reasoning as:<br>
"Motivation for disallowing * is somewhat philosophical, related to the semantics of datatype. Also related to the type of data models VO-DML is targeting. VO-DML is aimed at models that can give a conceptualization of a domain, rather than providing an implementation/serialization.
For the latter we have our VOTable mapping document for example, where the vo-dml is used in annotations.<br>
Idea is that if you have a collection-like concept for which you do not know how many instances you will have (i.e. multiplicity is *), it becomes a meaningful action to first state that such an instance exists and then that it is contained in the collection
on a certain object. Such a concept should be modelled by collection of object types, not list of data types."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">There are, however, several instances in the current model work where this approach has not been followed.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> STC2:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> - array of coefficients in a Polynomial transform definition<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">It is easy to create a very generic model of an N-dimensional polynomial as in the attached NDPolynomial.png.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">It defines the axes explicitly (the dimension is the size of the axis collection) and one may even want to add an identification between an axis and some observable.
The polynomial consists of a collection of Monomials that are assumed to be summed.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Each monomial is the product of one or more exponentiated axes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">What this model assumes is that it is meaningful to state that a particular polynomial, or expression, exists and that the definition of its terms, coefficients
and powers is meaningful as well. In fact when the polynomial is the result of fitting parameters one may wish to add uncertainty estimates to this pattern for example. More generally, one may wish to describe the provenance of the polynomial that has been
defined. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Compared to the “array of coefficients” this model is much more explicit, we do not have to rely on order in an array to define the power of the corresponding
term for example. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">And though this may not be relevant for some use cases considered in STC2, it even allows one to have negative or non-integer powers if desired.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In fact it is actually easy to generalize this pattern further to a generic mathematical expression as in figure Expression1.png or Expression2.png. The latter
includes Sum, Product and Power as instances of Function. This would allow us to describe transformations from Cartesian to spherical coordinates etc using the same model components.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
- number of coordinate values along an enumerated coordinate axis (Enum transform)<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I do not know what you’re referring to here, maybe other email explains.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Dataset:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> - Curation.reference = string[0..*]<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Using string as a serialization of an id identifying a publication. I.e. as a serialization of a reference.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><br>
- DataID.collection= string[0..*]<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Idem, using string to identify a collection. Most likely the association between dataset and collection can have further attributes, e.g. the id by which the
dataset is known in that collection etc.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><br>
- DataID.contributor= string[0..*]<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Idem, using name to identify a person contributing (“playing a role”) in the creation of the dataset. Likely could be further refined by describing the actual
role the person played. E.g. “creator”,”curator”,”publisher”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I have created a diagram (Dataset.png) linking Dataset to other concepts without the intermediate DataID and Curation types. It models these strings as references
and associative types. For example Contributor is a role played by a Party (a common design pattern to generalize Individual and Organization). Ths Party is also used for defining Authors of a Publication. Again, no need to discuss these in detail I think,
but I believe these simple models are already more explicit, and I would argue more “correct” than the implicit models relying on arrays of strings to (maybe) identify instances of some concepts that themselves are not explicitly defined.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
NOTE: the STC2 prototype also contains the above transform related items<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Cube:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> - PointData.customAxes = GenericCoord[0..*]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> a list of coordinate values not representable by the domain-specific coordinate types.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> GenericCoord is a dataType, so customAxes is an Attribute, and this multiplicity is not allowed.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Not yet looked at this.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> VO-DML<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
- Model.author = string[0..*]<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Please note first that VO-DML is *<b>not</b>* a conceptual data model written in VO-DML, it is a language for expressing data models
and there was no requirement to have it conform to its own rules. If you want it may be possible to consider it to be an application specific serialization/denormalization of a more comprehensive/normalized representation. Representing an “author” by a string
is clearly not doing justice to the Author concept, but makes it easier to write and parse/interpret a model document. If we think it is important to do something about it, in particular make it VO-DML compliant, the Party/Author pattern used above can be
used without much problems.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Plus some speculated cases which have not been modeled.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> - pixel data values in a spectrum<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Several models have already moved to describing pixels (or voxels) through a collection of objecttype-s on the parent similar to the attached Spectrum.png. Note
that I am not advocating this model in all detail, but it shows how one might gather relevant info in one objecttype. And note once more, serializations do not have to follow the model 1-1.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think in general our models, aimed as they are at annotation to assist interoperability/information integration, rather than at direct implementation, should
be more explicit about how data is obtained. I believe the measurement pattern as in
</span><i><span lang="EN" style="font-family:"Arial",sans-serif;color:#666666">uml2.narod.ru/files/docs/13/<b>AnalysisPatterns</b>.pdf</span></i><span lang="EN" style="font-family:"Arial",sans-serif;color:#666666"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Is useful. It was used in SimDB and originally in the “domain model” (for those who are old enough to remember this
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"> - number of samples in a time series.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> basically dimensionality of values; ndim[1], values[ndim]<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1F497D">I guess similar to previous case. No need to define ndim if the size of the collection of samples gives one that information.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
Gerard has suggested:<br>
"I think we should allow 0..n for attributes, but with a different interpretation from its counterpart in composition relations and references. It would imply that the value of the attribute is either 0, or an array of length exactly n. In relations the
interpretation remains that one can have between 0 and n (inclusive) instances in the collection."<br>
<br>
and added:<br>
"Allowing n to be an integer attribute with multiplicity 1 I am still strongly against. For example, what if, after initializing the 0..n attribute, you change the value of n?"<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Laurent argued that a Constraint definition would be able to deal with this. I agree with that. I think my main argument is that
this would introduce a kind of redundancy. Why have a separate integer attribute if the value of that concept could be derived from the length of the collection/array? My main point is that since this “solution” would leave it open to the instantiation to
decide how long the collection, it is apparently a meaningful statement to declare the existence of these instances, from which it follows (see my argument quoted by Mark above) that they should be represented as ObjectType-s.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">(Which is an excellent point. BTW)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
However, this suggestion does not, I think, resolve any of the above cases since the number of instances is not known.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Indeed, my main argument is that I think those examples are flawed and so I need not have made the.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
For the simple string cases, creating an object to hold the string datatype would resolve the compliance issue, but seems overly complicated. Once could argue that you wouldn't, necessarily, need to serialize the containers, but I would not like to see different
serialization rules for simple containers vs complex ones.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">It is only overly complicated if you ignore that in arguably all these cases a single string does not do justice to the concept that
is being represented. There are in general no serialization rules that must be followed. It generally will depend on the application how one wishes to do that.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
The more complex cases, one could/should question the modeling to be sure the approach is correct (on appropriate separate thread). Which may or may not find an alternate solution.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">For those requesting n = non-negative integer attribute with multiplicity 1:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"> perhaps in these cases, n is not a modeled property, but derived from the length of the array. if so,
<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
then these become open-ended values[*] which matches the above cases. constraints can restrict '* = 1,2,3'<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">So the issue is still un-resolved, and in my opinion, the string cases may be the better to focus on since they would generate the most overhead for the least benefit. We would have several objects, which simply
hold the primitive value<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Author.name:string[1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Reference.refString:string[1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Collection.tag:string[1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
Contributor.entity:string[1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">or maybe just<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Author.value:string[1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Reference.value:string[1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Collection.value:string[1]<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
Contributor.value:string[1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1F497D">I hope my alternatives show that in fact these things are related to referencing instances of ObjectTypes, and in our conceptual model should be modeled like that. BUT serializations can create patterns that
are similar to what you describe here, the extra annotation around them will simply make these mappings more explicit.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I'll close with an opinion on the suggested change to allow 0..n with special interpretation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I expect there may be use cases where there will be a need for optional fixed array attributes<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">(served by 0 OR n with literal n), but I don't think we've seen them yet. I think that using the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">notation 0..n will be widely misinterpreted when people are reading the model diagrams.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">The notation '0,n' would be more intuitive, but not standard. So, this feels like a combination
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
of multiplicity and constraint: multiplicity = '*' with constraint "* = 0,n"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1F497D">Fair enough. It really would be “0” or “n”, which is different from anywhere between 0 and n. Of course the context would make this clear, but if people think this is confusing, we
may come up with an alternate design for the Multiplicity class in Vo-DML.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1F497D">Cheers<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#1F497D">Gerard<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
Mark<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>