Re: [ENT] Review comments on the SPARQL 1.1. Entailment regime document

Chime,
I finally managed to take a look at the RIF section and I do have some comments:

Section 7 initial paragraph:
I might be missing something here, but you say:
"We will only define answers with respect to those RDF graphs that are
(simply) satisfiable and ..."
Does simply satisfiable here refer to RDF's simple interpretations? I
thought that any legal RDF graph has a simple interpretation, i.e., a
model under the simple semantics (no extra RDF(S) conditions/axioms
apply). Only under RDFS semantics it could happen that an RDF graph
has no RDFS interpretation due to mal-formed XML literals. If this
simple is some RIF term, I think it would be helpful to make that
clear because simple in the preceding parts of the document always
means the RDF simple. If it is RDF's simple, then that is redundant
isn't it?

There are still several places where we seem to enforce RIF strongly
safe core documents, which is no longer necessary given the relaxed
conditions on extensions to BGP matching.
"We will only define answers with respect to those RDF graphs that are
(simply) satisfiable and RIF-Simple-entailed by the combination formed
from the (skolemized) scoping graph and a referenced, ***strongly safe
RIF-Core*** [RIF-Core] document. "
URI in the table:http://www.w3.org/ns/entailment/RIF-RDF-***Strongly-Safe***-Core

Legal graphs in the table:
Any legal RDF graph. RDF graphs that either do not have a statement
with a predicate of rif:imports (see 7.1) or with more than one will
not be applicable to this entailment regime

Is that not the same as saying: Any legal RDF graph with exactly one
triples that has rif:imports as a predicate.
The current wording seems first to suggest that any RDF graph is ok,
but then immediately relativizes that to say that actually there are
constraints involving the rif:imports predicate. Furthermore, there
should probably be an editorial note saying the the prefix rif of
rif:imports is not yet decided and could be changed to something else
later on.

In the query answers part of the table you say:
A solution mapping μ is a possible solution ...
... and the ***strongly safe*** RIF core documents referenced from SG
via the rif:imports predicate.

That should probably be just solution instead of possible solution
because the purpose of that part in the table is to define solutions.
I use this two step process of possible solutions and then solutions
because I first take an entailment relation as it is, which gives
(possibly infinitely many) possible solutions. Ideally, I would just
declare this as solutions without messing around, but unfortunately
blank nodes and axiomatic triples can introduce infinitely many
redundant answers that nobody really wants to see. This infiniteness
is quite different than those that you get from recursive rules say.
Thus, I then go on and define which of all the entailed answers are to
be returned. The real answers are finite and the definition is chosen
such that in order to implement this, you can straight away just use
finite pre-completions/saturations a la ter Horst to compute the
answers for RDF(S), while it still nicely carries over to OWL Direct
Semantics, where you compute the answers usually differently, e.g., by
implementing a tableau algorithm.
Secondly, why is documents in the plural? I thought there can only be
one rif:imports predicate, which would imply that there is exactly one
such document.

SG:
ex:a ex:b ex:c.
[] rif:imports ex:d.
where ex:d is empty (just to have exactly one rif:import defined)

BGP: ?x ex:b ex:c.

sk: nothing is mapped, there are no bnodes in SG, so a mapping is not required

Now, of course, ?x/ex:a is a solution. But what about ?x/_:bn1? P(BGP)
is _:bn1 ex:b ex:c for an empty RDF instance mapping since BGP doe not
contain bnodes, and sk(P(BGP)) is _:bn1 ex:b ex:c since the Skolem
function just does not apply to _:bn1. This triple is, however, also
entailed and ?x/_bn1 is an answer and you can repeat this argument for
any bnode. The point is that sk is a Skolemization of the scoping
graph and it is not enforced that sk is also working on all bnodes
that can possibly occur in a BGP. What is really changing the
semantics is Skolemizing the basic graph pattern. I admit that when I
go from possible answers to answers, I throw out exactly those triples
that, when using the same Skolem function are not ground, so you could
argue that we could just define sk to be defined for all possible
bnodes, which is your hidden assumption I guess, but then all bnodes
in any BGP that do not occur in SG must also be mapped by sk.
The way sk is used in the other regimes just works wrt to SG under the
assumption that the Skolem constants do not occur in SG and BGP. This
means that in an implementation, you can actually leave SG as it is
and when you get a BGP that contains a bnode, then you treat that
bnode as a wildcard/variable that is projected away. E.g.:
SG:
ex:a ex:b _:c.
BGP:
?x ex:b _:d.
would have as answers ?x/ex:a because the RDF instance mapping could
map _:d to _:c and _:c occurs in the queried graph, so the
Skolemization of P(BGP) would yield a ground triple that occurs in the
Skolemized scoping graph. I find that conceptually nicer than assuming
that sk is defined for any possible bnode in any possible BGP. I
require only that the vocabulary for sk is disjoint from the
vocabulary of any BGP, but that can easily be achieved even without
knowing BGP because you can just pick a prefix that is not used in SG
and replace any underscore with that prefix. Should you get a BGP that
contains a constant that uses this prefix or is exactly one of the new
Skolem constants, you know that the BGP has no solution because the
constant in question cannot have been in the queried graph. Anyway,
long answer with mostly theoretical concerns ;-), but I would prefer
to use sk as in the other regimes or, if you don't want that, at least
say that sk is defined for any bnode in any BGP. What you could also
do is stay closer to SPARQL standard simple entailment. Already there,
if you don't have extra conditions, you have infinite answers from
bnodes and standard SPARQL requires that P(BGP) actually is a subgraph
of SG. That just doesn't work that well if you do inferences, e.g.,
even in ter Horst's complete RDFS algorithm, you have to introduce
bnodes in predicate position and then the question is whether these
should be returned in the answer etc.

7.1
...  However, for our scenario, the inverse of such a reference is
needed and a specific IRI is designated:
http://www.w3.org/ns/entailment/RDF-RIF-imports. In the subsequent
text, we will refer to this IRI as rif:imports.

Even if I define the prefix rif for http://www.w3.org/ns/entailment/,
that wouldn't give me rif:imports. An editorial remark would also be
good to make clear that the actual URI to which rif expands is not
really decided yet.

You continue:
... Combinations used in this SPARQL entailment regime must be
interpreted using the semantics specified in the Simple profile
(http://www.w3.org/ns/entailment/Simple) unless the RIF document
explicitly imports RDF or OWL using a profile with a higher precedence
(as specified in 5.1.1 Specific Profiles of the RIF RDF and OWL
Compatibility document)**.** (fullstop missing)

Now, the question is, what actually are the answers/solutions if I do
have an import that uses for example the OWL Full profile (I am
surprised BTW that RIF uses OWL Full and OWL DL to refer to the
semantics and not OWL RDF-Based and OWL Direct Semantics). The ent.
reg. document does not really specify that. It always assumes simple
semantics as per the table.

7.3
... This entailment regime restricts the legal graphs to only those
that refer to strongly safe RIF core documents. ...
That is no longer required. We can now allow also not strongly safe
RIF core documents, but in that case, finiteness is not guaranteed.
What the changed condition on extensions to BGP matching requires is
that trivial sources of infinite answers should be defined and
excluded by the regime. This is deliberately a bit vague, but answers
that just return different bnode labels are clearly in this category,
e.g., if I have
SG:
ex:a ex:b ex:c.
and query:
SELECT ?x WHERE { ?x ex:b ex:c }
I do not want to get:
_:a1, _:a2, _:a3, ... although _:a1 ex:b ex:c, _:a2 ex:b ex:c, _:a3
ex:b ex:c, ... are all entailed by SG. This should also be prevented
in the RIF regime, whereas recursive rules might also lead to infinite
answers, but such answers are not just trivial infinite answers.

Sorry that this got longer than intended...
Birte



On 18 May 2010 14:23, Chimezie Ogbuji <ogbujic@ccf.org> wrote:
> Maybe I'm missing something from this particular thread, but section 7.3
> Finite Answer Set Conditions (Informative) already that effect.
>
> -- Chime
>
>
> On 5/18/10 7:20 AM, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk> wrote:
>
>> That was my understanding too, i.e., we can also just have an
>> informative section (as RIF) that explains that by using only strongly
>> safe core rules, you get a nice guarantee for finiteness.
>> Birte
>>
>> On 18 May 2010 09:44, Axel Polleres <axel.polleres@deri.org> wrote:
>>>>>> Ok, I'll leave that one as is until there is further input
>>>>>
>>>>> I leave that to Axel and Sandro
>>>>
>>>> Unfortunately, I haven't had the time to follow this for a while.  How
>>>> urgent is this?  Things for me relax a little in two weeks, I think.
>>>>
>>>> Offhand, I'm unpleasantly surprised that anyone would want to name a
>>>> subset of Core.  Subsetting Core is bad for interoperability.  But maybe
>>>> there are issues I'm missing.
>>>
>>> If we don't require finiteness any longer, am not sure whether we need an own
>>> URI for strongly safe.
>>> We may just want to mention in the text that for strongly safe rulesets
>>> consequences will
>>> always be finite without the need for a separate entailment regime.
>>>
>>> Axel
>>>
>>>
>>>
>>> On 18 May 2010, at 04:54, Sandro Hawke wrote:
>>>
>>>>
>>>>> Hey Chime,
>>>>>
>>>>> Quick reply. Unfortunately, I cannot be on the call; I am on my way to =
>>>>> Sweden...
>>>>>
>>>>> On May 17, 2010, at 21:20 , Chimezie Ogbuji wrote:
>>>>>
>>>>>> Thanks for the review Ivan, see responses below for those comments =
>>>>> referring
>>>>>> to my sections.
>>>>>> =20
>>>>>> On 5/12/10 11:04 AM, "Ivan Herman" <ivan@w3.org> wrote:
>>>>>>> -----------
>>>>>>> Section 7
>>>>>>> =20
>>>>>>> At the moment, the http://www.w3.org/ns/entailment/ vocabulary does =
>>>>> _not_
>>>>>>> include the
>>>>>>> =20
>>>>>>> http://www.w3.org/ns/entailment/RIF-RDF-Strongly-Safe-Core
>>>>>>> =20
>>>>>>> but only
>>>>>>> =20
>>>>>>> http://www.w3.org/ns/entailment/RIF
>>>>>>> =20
>>>>>>> It is easy for me to add this additional URI, but I have to be sure =
>>>>> this is
>>>>>>> o.k. with the RIF group, and whether it is the correct name. And, if =
>>>>> I add
>>>>>>> this, shouldn't I add others? Which ones? Axel, Sandro, can you help =
>>>>> on that?
>>>>>> =20
>>>>>> Ok, I'll leave that one as is until there is further input
>>>>>
>>>>> I leave that to Axel and Sandro
>>>>
>>>> Unfortunately, I haven't had the time to follow this for a while.  How
>>>> urgent is this?  Things for me relax a little in two weeks, I think.
>>>>
>>>> Offhand, I'm unpleasantly surprised that anyone would want to name a
>>>> subset of Core.  Subsetting Core is bad for interoperability.  But maybe
>>>> there are issues I'm missing.
>>>>
>>>>>> =20
>>>>>>> -----------
>>>>>>> Section 7.1
>>>>>>> =20
>>>>>>> I think we have a pending issue as for which namespace rif:imports is =
>>>>> in. The
>>>>>>> current text does not specifies this at all. There should be a =
>>>>> namespace
>>>>>>> document, too.
>>>>>> =20
>>>>>> I have explicitly designated the following namespace URI:
>>>>>> =20
>>>>>> =20
>>>>>>            http://www.w3.org/ns/entailment/RDF-RIF-imports
>>>>>> =20
>>>>>> I'm not sure who is responsible for setting up the namespace document, =
>>>>> but
>>>>>> text from this section should be sufficient for the body of such a =
>>>>> document.
>>>>>
>>>>> I am the one maintaining these and Sandro can also do it. That being =
>>>>> said, I am not sure that is the right place to do this. The =
>>>>> .../entailment/XXX URI-s are used designate specific entailment regimes, =
>>>>> and this is something different.
>>>>>
>>>>> Ideally, this predicate should be in the rif namespace, but that would =
>>>>> require, I presume, an agreement from the RIF group (that again falls =
>>>>> into the domain of Sandro and Axel, I am afraid). We may have to mint a =
>>>>> URI of its own, which looks a bit silly....
>>>>
>>>> I don't see the rif namespace as a problem, if that's where it makes
>>>> sense to put it (whatever it is).  Either the RIF WG is okay with the
>>>> design, in which case it grants permission, or it isn't okay with the
>>>> design, in which case there are much bigger problems than the namespace.
>>>> Of course, the rif namespace is an XML namespace, not (yet) and RDF
>>>> namespace, but I'm hoping to make it both with the RIF-in-RDF encoding.
>>>>
>>>>    -- Sandro
>>>>
>>>>>> =20
>>>>>>> -----------
>>>>>>> Section 7.1
>>>>>>> In other words, I cannot dynamically assign rule sets to the dataset. =
>>>>> For a
>>>>>>> user this looks like a serious restriction because that means that =
>>>>> the dataset
>>>>>>> provider dictates the rule sets it has, rather than the user.
>>>>>>> =20
>>>>>>> Isn't it possible to say that the rdf:imports can also be part of the =
>>>>> BGP and
>>>>>>> has, well, the same semantics of referring to a rule set?
>>>>>>> =20
>>>>>>> Actually, the same question applies to various OWL regimes, too. Can =
>>>>> I have a
>>>>>>> [] owl:imports <...> in my BGP? Should we allow this?
>>>>>> =20
>>>>>> Per the thread with you and Birte on this, I have not done anything =
>>>>> since a
>>>>>> more fundamental change to the SPARQL syntax would be needed to =
>>>>> facilitate
>>>>>> query-time specification of a ruleset to use (and this was ruled out =
>>>>> early).
>>>>>
>>>>> Well... indeed, Birte convinced me that the current setup is actually =
>>>>> fine, and an import can be done via an extra graph that uses the import. =
>>>>> That being said, I do not understand your last remark: with the =
>>>>> semantics of rif:import one _can_ specify the rule set dynamically at =
>>>>> query time (provided the endpoint is capable of reading an RDF file at =
>>>>> an external URI). And that is the right thing to have!
>>>>>
>>>>> [snip]
>>>>>> =20
>>>>>>> -----------
>>>>>>> I wonder whether it would be good adding some additional (informal) =
>>>>> text in
>>>>>>> the RIF related text that makes it clear that, although we define the
>>>>>>> entailment regime only in terms of the RIF-Simple, it is possible to =
>>>>> define
>>>>>>> RIF Core rule sets that describe RDFS and even OWL-RL. Ie, with =
>>>>> suitable rule
>>>>>>> sets, this entailment is much more powerful than it looks at first. A
>>>>>>> reference to
>>>>>>> =20
>>>>>>> http://www.w3.org/TR/2010/WD-rif-owl-rl-20100511/
>>>>>>> =20
>>>>>>> and to ter Horst's paper (which, actually, still appears in the =
>>>>> reference
>>>>>>> list) would be useful.
>>>>>> =20
>>>>>> I've added a new section: 7.2 Custom Rulesets for Common Vocabulary
>>>>>> Interpretations (Informative) that discusses this.
>>>>>
>>>>> Yep! Thanks
>>>>>
>>>>> Ivan
>>>>>
>>>>>
>>>>>> =20
>>>>>> -- Chime
>>>>>> =20
>>>>>> =20
>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>> =20
>>>>>> P Please consider the environment before printing this e-mail
>>>>>> =20
>>>>>> Cleveland Clinic is ranked one of the top hospitals
>>>>>> in America by U.S.News & World Report (2009). =20
>>>>>> Visit us online at http://www.clevelandclinic.org for
>>>>>> a complete listing of our services, staff and
>>>>>> locations.
>>>>>> =20
>>>>>> =20
>>>>>> Confidentiality Note:  This message is intended for use
>>>>>> only by the individual or entity to which it is addressed
>>>>>> and may contain information that is privileged,
>>>>>> confidential, and exempt from disclosure under applicable
>>>>>> law.  If the reader of this message is not the intended
>>>>>> recipient or the employee or agent responsible for
>>>>>> delivering the message to the intended recipient, you are
>>>>>> hereby notified that any dissemination, distribution or
>>>>>> copying of this communication is strictly prohibited.  If
>>>>>> you have received this communication in error,  please
>>>>>> contact the sender immediately and destroy the material in
>>>>>> its entirety, whether electronic or hard copy.  Thank you.
>>>>>> =20
>>>>>
>>>>>
>>>>> ----
>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>> Home: http://www.w3.org/People/Ivan/
>>>>> mobile: +31-641044153
>>>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --Apple-Mail-20--508810017
>>>>> Content-Disposition: attachment;
>>>>>       filename=smime.p7s
>>>>> Content-Type: application/pkcs7-signature;
>>>>>       name=smime.p7s
>>>>> Content-Transfer-Encoding: base64
>>>>>
>>>>>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL8TCCAtA>>>>
> w
>>>>>
> ggI5oAMCAQICEEqSoKsbh13PhKdeqPhU+AowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkE>>>>
> x
>>>>>
> JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSB>>>>
> Q
>>>>>
> ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDkxODE2MDgwOVoXDTEwMDkxODE2MDg>>>>
> w
>>>>>
> OVowPTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEaMBgGCSqGSIb3DQEJARYLaXZ>>>>
> h
>>>>>
> bkB3My5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC38QtNc0tsiH1iMLGaGsi>>>>
> k
>>>>>
> Axy/xBYzndcKc0cIthO5pTxTJnJPMhKXMYjtDmBVPBDZgnII4BJ/ZgZTJonzqAsiCMn487kPE/P>>>>
> a
>>>>>
> s9fbu0ADxwKPPXuZELrpYQOirIGUiasa4l0xykA+kg/r6G8gLP0Vlc8yus4W5QnqIP4CwV/dDJL>>>>
> n
>>>>>
> /ibReADOD/dyzzSNhDYbOHQvvsbk657s8LGQvzgf52Y/NPw/3sMFXda3FUikiVvhK6P0yBz+kVA>>>>
> Z
>>>>>
> GLBBbDdHoSu9ESeLv9bhuNVHjtPRisQSHrWoMJIQ40tYRJjQDYJ3AZdaoAYMm/udUGyV9E9LKqx>>>>
> 6
>>>>>
> sI3OlmrV0wf733S/AgMBAAGjKDAmMBYGA1UdEQQPMA2BC2l2YW5AdzMub3JnMAwGA1UdEwEB/wQ>>>>
> C
>>>>>
> MAAwDQYJKoZIhvcNAQEFBQADgYEAAv9nnkFM0hFMc9C48LGyzaEkvUmPeX17O8Ko8bYRFOXrV2D>>>>
> p
>>>>>
> 8dUhHzJ8Zz3Kps5DoFpoE95SKOZATf4BZ/bL0bZOEgQukui0c3vJGQgcrYJefecQoPvrz8DL94u>>>>
> 0
>>>>>
> NHrfNkA2T+xPWYym7hSDGijbp8InLdp0FeGSM+a+iB4cSAswggM/MIICqKADAgECAgENMA0GCSq>>>>
> G
>>>>>
> SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQ>>>>
> H
>>>>>
> EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZ>>>>
> p
>>>>>
> Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1>>>>
> h
>>>>>
> aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDM>>>>
> w
>>>>>
> NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3R>>>>
> l
>>>>>
> IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWl>>>>
> s
>>>>>
> IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHU>>>>
> E
>>>>>
> cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/E>>>>
> f
>>>>>
> kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgM>>>>
> B
>>>>>
> AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3J>>>>
> s
>>>>>
> LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQY>>>>
> D
>>>>>
> VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4G>>>>
> B
>>>>>
> AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl>>>>
> +
>>>>>
> hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXi>>>>
> C
>>>>>
> 3CEZNd4ksdMdRv9dX2VPMIIF1jCCA76gAwIBAgIDCEl3MA0GCSqGSIb3DQEBBQUAMHkxEDAOBgN>>>>
> V
>>>>>
> BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0E>>>>
> g
>>>>>
> Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3J>>>>
> n
>>>>>
> MB4XDTEwMDMwMTEzNTM1NFoXDTEwMDgyODEzNTM1NFowgaQxGDAWBgNVBAMTD0NBY2VydCBXb1Q>>>>
> g
>>>>>
> VXNlcjEjMCEGCSqGSIb3DQEJARYUaXZhbkBpdmFuLWhlcm1hbi5uZXQxGjAYBgkqhkiG9w0BCQE>>>>
> W
>>>>>
> C2l2YW5AdzMub3JnMSQwIgYJKoZIhvcNAQkBFhVpdmFuLmhlcm1hbkBnbWFpbC5jb20xITAfBgk>>>>
> q
>>>>>
> hkiG9w0BCQEWEml2YW4uaGVybWFuQGN3aS5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQo>>>>
> C
>>>>>
> ggEBANJMSIlShzh2egaUn2Yrt4CkXuJxb8t6oNJz9kmquJ3cop6YVamwe9BIuQEoyoXav73jaVm>>>>
> 1
>>>>>
> x+HYLF+iOFKD+qGIWEILpxvXeJkshtR/uLT0a5yYcpC3cV4oEF40rDdkhVe+CHyyrmgNMk+7+DE>>>>
> D
>>>>>
> /8bcAtTL5plcckrY3FooZjWI9kkJqy+enWvX+OECgP+Ab89in3BzIWYn2y4cdunzKVaWtq4/iap>>>>
> D
>>>>>
> 6eKNgaQc//PTTmJ/M+rWcZupdKtxs9hq/490vTYuz2Fpqhg4CBK/OMeGro0Xe8Vvj2DeWseWh90>>>>
> g
>>>>>
> ZZDGVVveZLWEnU8kQZ3ovDIOudO/UekIILxerVpM0HcCAwEAAaOCATkwggE1MAwGA1UdEwEB/wQ>>>>
> C
>>>>>
> MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSB>>>>
> o
>>>>>
> ZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBgg>>>>
> r
>>>>>
> BgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCY>>>>
> w
>>>>>
> JDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBXBgNVHREEUDBOgRRpdmFuQGl>>>>
> 2
>>>>>
> YW4taGVybWFuLm5ldIELaXZhbkB3My5vcmeBFWl2YW4uaGVybWFuQGdtYWlsLmNvbYESaXZhbi5>>>>
> o
>>>>>
> ZXJtYW5AY3dpLm5sMA0GCSqGSIb3DQEBBQUAA4ICAQBdESSYBnnSVwQeV+YFarYCz6wjbFgY4lf>>>>
> R
>>>>>
> HeHKZK1y5xU6f6KHXFyd/FE4pFR8Ng9Tg3rishKMSvSkt/uFBl3tDkQgKY9zHr0XDbGNqwCXoxX>>>>
> s
>>>>>
> Q1jKp28THxs9oq0S6DMG9JX+dl9ocS46x1Ntoy3szPk4wwKkGbCEZAz10EvtA3at6O6Aw+/iP84>>>>
> F
>>>>>
> PTS/rH3I3svCDxc8OfW6FiQoV2oUOfIIZpaLUM5ESwZ8VKEcQB1GhWLdfyc0xmYHF6Tbl+eBPb2>>>>
> E
>>>>>
> XdTBaIcbwABhWtXVO+P0HMnBwTHxbSii8s3JF9hNiBe9kdgKf4CD+26sZ49NHfIax5xeyb8eCfc>>>>
> s
>>>>>
> /wd5NFDxIamEc0dMFvigC5i7zfUmoBsvnRtt+2r1DcGofLm25zoB4KVloYpNNg/jbxvgn3D/NhE>>>>
> f
>>>>>
> xIbko8bxBO74zG4VZ4NvBzGaaEY3Y3VXX2iqF3hmf1QarfqVs3onDVfKkKD0gFEm1AuXWnOaCnF>>>>
> G
>>>>>
> CNgOG2DUGklmJ4j/GaOEDdgr5cwSammwQoV7A2fRH+At7P8/TU7SmNP+vVXl7JWTDCzVFnMLHWE>>>>
> T
>>>>>
> 5FZUkAB6Ew5opeKTfJAlrdbNDHhvDy+abcQDUeSMXDq08AzlyruPqu81FOzy8Hj3rkrDD+VAd/J>>>>
> s
>>>>>
> t0AA/ymK6kZC8M2gT2+HbOVX2lAb43yTaIPyMZ8o3TGCAxswggMXAgEBMIGAMHkxEDAOBgNVBAo>>>>
> T
>>>>>
> B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2V>>>>
> y
>>>>>
> dCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgM>>>>
> I
>>>>>
> SXcwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQU>>>>
> x
>>>>>
> DxcNMTAwNTE4MDI1MjEzWjAjBgkqhkiG9w0BCQQxFgQUr2QvNQZu9OhwFT+pCdI5jcfBlOkwgYU>>>>
> G
>>>>>
> CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5>>>>
> n
>>>>>
> IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIEN>>>>
> B
>>>>>
> AhBKkqCrG4ddz4SnXqj4VPgKMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTA>>>>
> j
>>>>>
> BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJ>>>>
> z
>>>>>
> b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBKkqCrG4ddz4SnXqj4VPgKMA0GCSqGSIb3DQEBAQU>>>>
> A
>>>>>
> BIIBAF0NV3nZIXAYrpOQZ83q8CXOopFRwUHrBSmeqBfwrbNUoQYznNeyhCmTcSmx4pmRI+flc1T>>>>
> e
>>>>>
> y2XXqTLlnExL2jjDs75f4/FmXhMFoGPOORmWoF4Fx4b3dFxLg7u0XcFiZg06ynzsS0AIoiEoS78>>>>
> n
>>>>>
> iBadU1QSAA/nGXwpUyfhPiug0ZHSmGv+OOwbnNR8N0S0o4V2IAhv5YQ3MLirXa76zOB8yHFGuWJ>>>>
> b
>>>>>
> IfCgzF9MYoN+oKaBAJjn8C1UIFrNFjUhyF5c2kZGzm7bJCKBupwwQQqISbcVk+FTEUN46MAq7B4>>>>
> 8
>>>>> WmE9QXWF616ychOS4i8OCESmOBOr/dQjOOsu7pXvuTMAAAAAAAA=
>>>>>
>>>>> --Apple-Mail-20--508810017--
>>>>
>>>
>>>
>>
>>
>
>
> ===================================
>
> P Please consider the environment before printing this e-mail
>
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S.News & World Report (2009).
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
>
>
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
>
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Tuesday, 18 May 2010 18:44:13 UTC