Re: comments on current version BLD document: symbols, datatypes, semantics

> >>>> 6- section "symbol spaces" second paragraph, first sentence: symbol
> >>>> spaces are actually not subsets of the constant symbols in RIF.  First
> >>>> of all, a symbol space is not a set; second, constant symbols are pairs
> >>>> (literal, symbol space IRI). I would propose to rephrase this sentence
> >>>> to something like "every constant symbol in the RIF as an associate
> >>>> symbol space"
> >>> They are named subsets. (I added "named" to their abstract definition).
> >> they are not subsets, because symbol spaces are pairs of lexical spaces
> >> and identifiers
> > 
> > Symbol spaces are defined as subsets of the set Const of all constants.
> 
> I was thrown off by the phrase below the definition, which says "Each
> symbol space is described through its lexical space and its
> identifiers.", which appears to be a definition.
> I would propose to rephrase it to something like "Each symbol space has
> an associated lexical space and a number of identifiers."
> Furthermore, I would propose to start the definition of symbol spaces on
> a new line, rather than in the middle of a paragraph.
> Finally, I would prefer it if it is written explicitly what this subset
> of Const, which is the symbol space, actually looks like (i.e. a set of
> pairs).  I think it is more readable if this is spelled out, rather than
> it being implicit in the text.

OK. I made the changes that you suggested. I do not quite see how to
implement your last suggestion without making the sentence look bad.
If you have a concrete suggestion, please send it to me. Take a look at how
it looks now.


> >>>> 2- section "signatures and a condition language of RIF^BLD^": the
> >>>> definition of equality atoms is not entirely clear: the symbol = is not
> >>>> a constant symbol in RIF, according to the syntax definition in section
> >>>> "presentation syntax" (it does not have the symbol space).  Furthermore,
> >>>> as it is correctly mentioned that equality is not a built-in predicates,
> >>>> I feel there is an impedance mismatch between this predicate symbol and
> >>>> all other kinds of predicate symbols.  Finally, equality is currently
> >>>> not mentioned when atomic formulas are initially defined.  Therefore, I
> >>>> would propose to define equality atoms a=b directly when first defining
> >>>> atomic formulas.
> >>> A good point! You were looking at a version before I moved = further down,
> >>> but the point about its symbol space is well-taken. It should be either
> >>> rif:local (my pref) or rif:iri.
> >>>
> >>> I experimented with requiring all symbols to have explicit symbol spaces in
> >>> the examples, but I think they become unsightly due to that. Perhaps we
> >>> should not require ^^rif:local explicitly. Then we could write a=b as
> >>> before.  If people think that we should insist on explicit symbol space
> >>> names (as it is done now, to make the syntax look more abstract and devoid
> >>> of syntactic sugar) then I am fine with writing a =^^rif:local b or even
> >>> equal^^rif:local(a,b).
> >> This does not yet address my concerns about the impedance mismatch
> >> between the equality symbol on the one hand, and predicate symbols on
> >> the other: Predicate symbols are interpreted as sets of tuples, whereas
> >> equality is interpreted as identity.
> > 
> > Equality is a set of tuples -- it was just defined differently, but
> > equivalently. I'll change its definition so that it will look like a normal
> > predicate. But it is a good point. Other than that, would =^^rif:local
> > satisfy your objection? (I already did it).
> 
> I would prefer = to be a special symbol in the language, rather than a
> predicate symbol with a special interpretation.
> However, I can live with the current definition.


Why should it be a special symbol when it is just a predicate?


> >>>> 3- section "symbol spaces": why is the lexical space of the symbol space
> >>>> non-empty?  Why not simply define it as a set?  I think it does not hurt
> >>>> to allow empty lexical spaces.
> >>> A symbol space defines a set of constants. If the lexical space is empty,
> >>> the set of constants is empty. Does not make sense to contemplate such sets
> >>> of symbols in the syntax, IMO.
> >> Well, I can easily think of cases where one would want an empty symbol
> >> space. I can, for example, easily imagine rule sets which do not use any
> >> local identifiers, so the lexical space of the rif:local symbol space
> >> will be empty.
> >> furthermore, the definitions just become more complicated by requiring
> >> the sets to be nonempty.
> > 
> > The lexical space of rif:local is never empty. It is defined by RIF in a
> > concrete way.
> > Does not matter if a particular rule set or language uses that or not.
> > There is no side effect.
> 
> This doesn't address my point about definitions becoming more
> complicated.  I simply don't see why we would need such a requirement.

And I do not see why should we allow things that make no sense.  Why do we
need to even consider allowing empty named subsets of the overall sets of
constants?

> >>>> 4- section "symbol spaces": there should be a restriction on the kinds
> >>>> of datatypes which may be used.  Namely, the lexical-to-value mapping
> >>>> and the value space need to be well-defined;
> >>> what do you mean by that?
> >> Say, you are using a datatype with an ill-defined value space, e.g.
> >> xsd:duration.
> >> If you have a symbol "xx"^^xsd:duration, the value
> >> IC("xx"^^xsd:duration) is not well defined, so the interpretation is not
> >> well defined.
> > 
> > "xx"^^xsd:duration is *not* a constant in rif.
> > I guess you are talking about "unknown" symbol spaces. In that case tey are
> > not going to be treated as data types and their value space will not be defined.
> > It is an omission in the semantics section (now fixed). 
> > 
> >>>> now, the RIF
> >>>> semantics is not well-defined. The text in the paragraph "symbols with
> >>>> ill-formed lexical parts" will then need to be updated accordingly.
> >>>> 5- "symbols with undefined symbol spaces": the description in this
> >>>> paragraph is incorrect, since, if the symbol space corresponds to a
> >>>> known datatype, and implementation will interpret the symbol according
> >>>> to this datatype.  I propose to remove this paragraph.
> >>> You were the one who proposed this paragraph in the first place. 
> >> That was when the datatype support in the RIF was not yet extensible.
> >> Now it is, so the paragraph is out of date.
> > 
> > I do not understand that. In fact, I now added another paragraph about
> > unknown spaces in the semantic section.
> > 
> >>> Second, I
> >>> do not really understand what you are saying.  The paragraph you are
> >>> referring to talks about "undefined" symbol spaces, while in the above you
> >>> are talking about the known spaces.
> >> yes, the terminology is a bit confusing.  RIF "defines" a number of
> >> symbols spaces, but people can use additional symbol spaces which
> >> correspond to /known/ datatypes.
> >> So, we have a number of symbol spaces defined by the RIF; of these
> >> symbol spaces, those which corresponds to datatypes, correspond to
> >> /known/ datatypes (by definition). There are a number of other symbol
> >> spaces which corresponds to datatypes.  Some of these will correspond to
> >> known datatypes, and some will corresponds to unknown data types.
> >> I interpreted an "undefined" symbol space as a symbol space which is not
> >> "defined" by RIF.
> > 
> > This is something I fail to understand. What is a known but unsupported
> > data type? We list the data types that are known and supported and all the
> > rest are unknown and unsupported as far as RIF is concerned.
> > 
> > You cannot build an implementation of a logical system based on some
> > undefined or unknown concepts.
> 
> I had written my comments under the assumption that we agreed to make
> datatype support in the RIF extensible.  Clearly, we both understood
> something different from this agreement.
> 
> The way I see extensibility of data type support, we should allow the
> use of data types which are not supported by RIF, but which are known by
> the agent processing the RIF descriptions.  And with "use" I mean that
> the RIF semantics should allow to derive equalities which follow from
> such datatypes.
> As Dave pointed out in the face-to-face, RDF and OWL implementations do
> not seem to have a problem with this kind of extensibility.
> 
> 
> (I am sending a proposal for a text which facilitates this in a separate
> e-mail)

I am ok as long as the proposal makes sense to me.
(I am yet to read it and will respond.)


> >> By the way, it is exactly this confusion which led me to propose to use
> >> datatype maps.  Interpretations will be defined with respect to a
> >> datatype maps, which includes all the /known/ datatypes.
> > 
> > Data type maps is one of the most confusing and ill-defined concepts that I
> > came across.
> 
> I do not really see what is confusing or ill-defined about datatype
> maps.  A datatype map is simply a mapping from URIs to data types.

It defines a semantics based on an unknown component. It might be that the
description of datatype maps is just confusing or I did not understand it
properly. I'll read your proposal and see if I understand it.

> >>>>    a- it is hard to grasp from the definition how a single constant
> >>>> symbol is interpreted; it is necessary to carefully read and try to
> >>>> understand all the (too lengthy) text. The definitions can be much
> >>>> crisper, as I showed in earlier proposals for this definition.
> >>> I do not think that the text is either lengthy or that it is not crisp
> >>> enough.
> >>> I believe that this is similar to your earlier proposals. If you have a
> >>> specific text to propose, please do so.
> >> OK, I will send a proposal in a separate e-mail.
> > 
> > Please take into account the recent updates.
> > 
> >>>>    d- no distinction is being made between the identifier of a symbol
> >>>> space and the symbol space itself, whereas they are different things
> >>> Where did you find that?
> >> For example, you talk about things like "the symbol space rif:text".
> >> However, rif:text is the identifier of the symbol space, and not the
> >> symbol space itself.
> > 
> > Well, this is quite acceptable. People do this all the time when confusion
> > does not arise. I was asking about the places where the use of "the symbol
> > space rif:text" as opposed to "the symbol space *named* rif:text" causes
> > confusion.
> 
> OK.
> I would propose to add a phrase like "In the remainder  of the document
> we use the identifier of a symbol space to denote that symbol space."
> when introducing symbol spaces.

OK

> >>>>    e- according to the second bullet in "the effect of the symbol
> >>>> spaces", the mapping IC(lit^^symsp) should be defined for every constant
> >>>> symbol of the form lit^^symsp with lit in the lexical space of the
> >>>> symbol space identified by symsp.  This would mean that every such
> >>>> symbol is in the vocabulary of every RIF language. I think this is
> >>>> highly undesirable (and should have been mentioned in the syntax
> >>>> section). The mapping should only be defined for symbols in the vocabulary.
> >>> We are defining a logic, including some specific sets of symbols that
> >>> belong to the language of that logic.
> >> Yes, but it is not necessary.  Why not let the user decide exactly which
> >> of the symbols to use?
> > 
> > The user can use or not use whatever symbols they want. This has absolutely
> > no effect on the user! When you define a language of a logic, you are
> > defining a language for that logic, not for a particular set of formulas in
> > that logic. This is a standard textbook way of doing things.
> 
> In most text books, papers, and standard specifications I read
> (including your own paper [1]) this is not the way of doing things.
> The usual definition of a logic looks something like:
> Given some set of symbols A ( i.e. vocabulary/alphabet/signature ), the
> language LA is the set of formulas constructed using the symbols in A
> and the logical connectives.......

Exactly. This is precisely what we are doing in RIF right now (and
precisely what I said above).
I may have misunderstood what you said earlier:

     This would mean that every such symbol is in the vocabulary of every
     RIF language. I think this is highly undesirable (and should have been
     mentioned in the syntax section).

Indeed, every such symbol is in the vocabulary of every RIF language.
I am yet to understand why is it "highly undesirable."

The standard way is to first define an alphabet (which includes all the
symbols, connectives, etc.) and then define the rules for putting the
alphabet symbols together into formulas.  This is not explicitly mentioned
-- an omission. It is mentioned now. In fact, there was a bad typo, which
said "The language of RIF ..." while it should have been "The alphabet of
RIF ...".


> I don't really understand why we should do something different.

We are not.


> [1] Michael Kifer, Georg Lausen, James Wu: Logical Foundations of
> Object-Oriented and Frame-Based Languages. J. ACM 42(4): 741-843 (1995)
> 
> > 
> > 
> >>> Your claim that this is "highly undesirable" requires at least some explanation.
> >> OK, because it is syntax my claim is probably a bit too strong.  The
> >> thing is that it is simply unnecessary to include all these constants in
> >> the vocabulary of every language, so why would we do it?
> > 
> > See above.
> > 
> > 
> >> An additional drawback is that if we were to consider a dialect which
> >> has a semantics based on Herbrand universes, all these symbols are
> >> included in the universe. This would have certain undesirable
> >> implications, e.g. ( considering a dialect with negation):
> > 
> > You are completely wrong. Herbrand universes are defined with respect to
> > the symbols mention of the rule set, not with respect to the symbols in the
> > entire logic language.
> 
> There are certainly papers where the Herbrand universe is defined with
> respect to a vocabulary (e.g. [2]), since such a definition is more
> general (in the mentioned paper the symbols in the Herbrand universe
> which are not in the rules are used for queries to an external knowledge
> base).

So, you can use whatever definition you want. The standard definition uses
the symbols in the program only, and there are two or three other
definitions, which talk about extended universes and such.
You did not say which definition you use, so I assumed the standard one.
In any case, I fail to follow your line of reasoning.

> [2] Thomas Eiter, Thomas Lukasiewicz, Roman Schindlauer, Hans Tompits:
> Combining Answer Set Programming with Description Logics for the
> Semantic Web. KR 2004: 141-151
> 
> >>>>    g- the value space is required to be a subset of the domain.  This
> >>>> means that every interpretation includes all value spaces of all data
> >>>> types.  This is unnecessary.
> >>> So what? It makes the definition simple and uniform.
> >> It makes every domain infinite. For most kinds of rules (especially
> >> those without equality in the head) this is not really a problem.
> >> However, as soon as we have full use of equality, or deal with
> >> extensions in the direction of FOL, then one often wants to talk about
> >> finite models.
> > 
> > You can still talk about finite models. 
> 
> How?  Every model is infinite.


You need to look at the relevant parts of the models, which would be finite.

If you want data types, then their symbols are part of the alphabet. If
they are, the universe is infinite. You are trying to introduce something
quite non-standard to bend the definitions to look in a nonstandard way
because of your personal aesthetic views.

> > If you are not going to use
> > infinite relations then you are fine. If you are going to use infinite
> > relations then you do not have finite models anyway. Equality is
> > never a problem in this setting, because it is interpreted as identity.
> > 
> >> It also makes rule sets which only contain rules such as Forall ?x,?y
> >> (?x=?y)  inconsistent. I claim that this is undesirable.
> > 
> > I claim that this is YGWYD (you get what you deserve). Such a statement
> > should be treated as inconsistent if you are using data types.
> > 
> > Although I do not agree with any of your arguments about undesirability, I
> > am ok with changing things so that value spaces will not be required to be
> > a subset. To this end, I added a note in the appropriate place stating that
> > you are proposing a certain change. Let the people decide!
> > 
> > 
> >> On a side note, some extensions (and possibly a combination with OWL DL)
> >> will want to separate the (concrete) interpretation domain for datatypes
> >> from the individual (abstract) interpretation domain in order to be able
> >> to do effective reasoning.
> >> I believe we currently do not have such a mechanism (to separate the
> >> two), do we?
> > 
> > I am not sure what you mean.
> 
> In Description Logics, a distinction is made between the abstract domain
> and the concrete domain. The value spaces of data types are subsets of
> the concrete domain.
> Each predicate symbol has a signature (e.g. abstract x abstract or
> abstract x concrete) which determines which kind of symbols can be used
> there.
> Data values are interpreted in the concrete domain, and variables
> quantify either over the abstract or over the concrete domain.
> 
> Because of this strict separation between the abstract and concrete
> domains, reasoning with data types in Description Logics can be done
> through issuing conjunctive queries to a datatype oracle.

So, take U minus the value spaces of data types, and this is your abstract
domain. You are splitting hairs. Nah, you are arguing about something that
is even less interesting than splitting hairs. :-)


	cheers
	  --michael  


> Best, Jos
> 
> > If you are not using data types then you can
> > map the thing into a theory where data types are not used.
> > 
> > 
> > 	--michael  
> > 
> > 
> >> Best, Jos
> 
> -- 
>                          debruijn@inf.unibz.it
> 
> Jos de Bruijn,        http://www.debruijn.net/
> ----------------------------------------------
> In heaven all the interesting people are
> missing.
>   - Friedrich Nietzsche
> 
> --------------ms050302090700090605050603
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJEzCC
> AuQwggJNoAMCAQICEB1TmNgyHOKRUL43eSjaINgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
> BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
> I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUxMDA3NTMwOFoX
> DTA4MDUwOTA3NTMwOFowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG
> CSqGSIb3DQEJARYVZGVicnVpam5AaW5mLnVuaWJ6Lml0MIIBIjANBgkqhkiG9w0BAQEFAAOC
> AQ8AMIIBCgKCAQEA4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ
> 1lhTAFjCVjasdS61TpwsYWWzrNfygNKHPVvmDWJRDVUCyqvsLUhhWiIT2GoJCKlWXXpzNdWQ
> e1pXwFCLVniOD+SrWXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcU
> NI5r/690Htyck7nmc+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+D
> p5SjScZiJEYMYk06X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwID
> AQABozIwMDAgBgNVHREEGTAXgRVkZWJydWlqbkBpbmYudW5pYnouaXQwDAYDVR0TAQH/BAIw
> ADANBgkqhkiG9w0BAQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2
> nKrfoev1IXti4w/IY8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppc
> uuppnlj+MKk25ZRFoXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAuQwggJNoAMCAQIC
> EB1TmNgyHOKRUL43eSjaINgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNV
> BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz
> b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUxMDA3NTMwOFoXDTA4MDUwOTA3NTMw
> OFowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYV
> ZGVicnVpam5AaW5mLnVuaWJ6Lml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
> 4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ1lhTAFjCVjasdS61
> TpwsYWWzrNfygNKHPVvmDWJRDVUCyqvsLUhhWiIT2GoJCKlWXXpzNdWQe1pXwFCLVniOD+Sr
> WXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcUNI5r/690Htyck7nm
> c+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+Dp5SjScZiJEYMYk06
> X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwIDAQABozIwMDAgBgNV
> HREEGTAXgRVkZWJydWlqbkBpbmYudW5pYnouaXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B
> AQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2nKrfoev1IXti4w/I
> Y8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppcuuppnlj+MKk25ZRF
> oXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN
> AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
> CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
> ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
> cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
> bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD
> VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
> c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
> xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV
> cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
> VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG
> A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy
> ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp
> dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX
> oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx
> VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
> ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
> ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
> ZyBDQQIQHVOY2DIc4pFQvjd5KNog2DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ
> KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMTUwOTMxMTBaMCMGCSqGSIb3DQEJBDEW
> BBTtKN7CHptqJY2AFN5fY+yjgAiTlzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
> CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB
> hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
> bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz
> c3VpbmcgQ0ECEB1TmNgyHOKRUL43eSjaINgwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD
> VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
> AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB1TmNgyHOKRUL43eSja
> INgwDQYJKoZIhvcNAQEBBQAEggEAaGnGbB670H4hX3sF5wZb7Ab8YPZKjdVeGWe1GZe9tWiv
> WFgwt9gHk3xiBnzHAW5ygkvVjlYYVHNIoPsX4dCgmKD1+oOiTgcd1mlFtKOT7tGk4PCrEKEk
> /zKom31WnXGpMsx1r62LTfZCgsz9bN5LSI8IvzUnvP7KrN88BGIStb+0DFdYat4+xc9232KD
> FfiPaXTEBYbQ1N95nVIxrgRpi6uvrXggG1+2s+MEFXzrNmclBWtK90ZPygaNV6m27VuNRSSc
> NoGJSSbzS85nIeMIA0lV+lWILJQcnaTl096NJzagU+2j+/QXiWUuVR/SLaHgTyO8307Svyob
> lr6h2r5kOQAAAAAAAA==
> --------------ms050302090700090605050603--
>

Received on Monday, 15 October 2007 19:56:46 UTC