[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Thoughts in Modeling Personas in XDI
--Apple-Mail-249--1052465000
Content-Type: multipart/alternative;
boundary=Apple-Mail-248--1052465128
--Apple-Mail-248--1052465128
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Agreed.
If the common use cases are not easily understandable by unsophisticated =
developers, then adoption will not happen.
Remember XDI is competing against key value pairs (claims) and people =
have a hard enough time with that.
We skipped over simple Authority Type Instance, and dove into the deep =
end of RDF.
It has a certain elegance, but if this group can decide on statement =
equivalence etc then what chance will normal developers have?
Shipping code always beats the stuff that never makes it out of the =
labs.
John B.
On 2010-11-25, at 5:03 PM, Markus Sabadello wrote:
> I agree with both Mike and Giovanni. :)
>=20
> It is seducing to embark on a Faustian quest to build the ultimate =
semantic reasoning monster that can do everything from implementing =
whatever is the latest and hottest logical calculus, to finding the very =
essence of life and making all the semantic web utopists pee in their =
pants. How realistic this is in the face of armies of PhDs that have =
tried it with RDF, I am not sure about.
>=20
> So, if the goal is to make XDI useful and gain adoption quickly
> --> Do what Mike says, concentrate on 99% of the practical use cases =
(in other words, forget all the semantic stuff), write the specs in the =
next 2-4 weeks, and be done with it.
>=20
> If the goal for XDI is to be a hobby that can keep us entertained for =
the next few years, or to be a long-term marketing vehicle for other =
projects
> --> Just continue what we're doing now.
>=20
> Markus
> --=20
> blog: http://danubechannel.com
> phone: +43 664 3154848
>=20
> On Thu, Nov 25, 2010 at 3:02 PM, Giovanni Bartolomeo =
<giovanni.bartolomeo@uniroma2.it> wrote:
> Hello Mike,
>=20
> sorry to disagree with you.
>=20
> Unfortunately, in standards which involve semantics you cannot satisfy =
80% of requirements, and ignore the remaining 20%, because the latter is =
likely to make fail the whole system: actually one single contradiction =
in a semantic model is enough to invalidate all your reasonings.
>=20
> Please take a look at this message from Bill:
>=20
> http://lists.oasis-open.org/archives/xdi/201008/msg00022.html
>=20
> which explains in an easy way why semantic matters are so essential to =
answer the question "What is XDI good for?"
>=20
>=20
> Best Regards,
> Giovanni
>=20
> Def. Quota "Michael Schwartz" <mike@gluu.org>:
>=20
>=20
> I'd rather be good than perfect here.
>=20
> I think we should support the easiest use cases, and we will probably =
end up satisifying 80% of the requirements. If we fail to get out a =
standard, we will satisify 0% of the requirements.
>=20
> If we are going to get these standards out, I suggest we take the path =
of least resistence on these symantic questions. What are the real world =
requirements to support these semantics? Let's focus on the semantic =
problems have the most real world applications.
>=20
> This will help XDI address its biggest marketing challenge: What is =
XDI good for? I think we need a new "get to market" approach, or we will =
never get to the finish line.
>=20
> - Mike
>=20
>=20
>=20
>=20
> =
--------------------------------------------------------------------------=
------------
>=20
> Michael Schwartz
> Gluu
> Founder, CEO
> https://www.gluu.org
>=20
>=20
>=20
> On Wed, 24 Nov 2010, Giovanni Bartolomeo wrote:
>=20
> Hello Mike, Bill,
>=20
> Thak you Mike for disclosing this. Here is what's my problem about =
approach (see also last week's minutes here: =
http://lists.oasis-open.org/archives/xdi/201011/msg00023.html, bullet =
#3)
>=20
> +work, +home, etc., semantically, are not properly attributes of a =
person - even if it, for reasons related to specific programming =
environment constraints, they could be implemented as such.
>=20
> However, it has extremely complex implications to interpret them as =
"part of" a person in the widest sense it could be possible to interpret =
it without violating the mereological principle I was referring in my =
previous email (assumed we all agree on it).
>=20
> As Bill says:
>=20
> perhaps a better way of translating it might be thinking of +work as =
actually
> +worker, and +home as +resident.
>=20
> this is something I like better, as it shifts the perspective from =
+work, +home to be attribute to a PoV which considers them as =
"qualities" of a person (not attributes), i.e. alice qua +worker, alice =
qua +resident, etc. This is better modeled using the generalization =
pattern, not the aggregation pattern.
>=20
> For example, in OO programming, once defined =3Dalice as an object =
inheriting from both classes +worker and +resident, =3Dalice inherits =
different (proper) attributes belonging to these classes, e.g. she may =
have two different telephone numbers (one for work and one for home), =
two different addresses (one for work and one for home), and so on.
>=20
> This is what I would exactly express with =
@example.bus.company+worker=3Dalice and @NYC+resident=3Dalice.
>=20
> Note that in former times, we used to say that =
@example.bus.company+worker=3Dalice/$is$a/=3Dalice and =
@NYC+resident=3Dalice/$is$a/=3Dalice, two statements that just remark =
the inheritance pattern above mentioned.
>=20
> Also, this makes it easier and clearer to refer to the same attributes =
in different contexts, e.g. @example.bus.company+worker=3Dalice+address =
is (may be) different than @NYC+resident=3Dalice+address. Note the =
similarity with e.g. Java: ((Worker)alice).address and =
((Resident)alice).addres
>=20
> What do you think?
>=20
> Best Regards,
> Giovanni
>=20
>=20
>=20
> Def. Quota "Michael Schwartz" <mike@gluu.org>:
>=20
>=20
> Maybe I can shed some light on Gluu's implementation, and this could =
provide a concrete example.
>=20
> This first kind of role Drummond is referencing is either an attribute =
of the person, in which case no special consideration needs to be given: =
it can be handled as any other attribute. Or its represented as a group. =
At Gluu, the organization, the person and the group all have i-numbers =
in our directory service. And the groupMembership is also referenced in =
the memberOf attribute of the person (so again, group membership =
basically looks like an attribute of the person).
>=20
> Personas at Gluu are represented as sub-entries of the person. For =
example: inum=3DX1,ou=3Dpeople,o=3DY,o=3Dgluu, where X1 is the inumber =
of the person and Y is the i-number of the organization. A person would =
be inum=3Dz1,ou=3Dpersonas,inum-X1,ou=3Dpeople,o=3DY,o=3Dgluu. =
Furthermore, if we have a new person, X2, who is friends with X1, he may =
have a contact: inum=3Dz2,ou=3Dcontacts,inum=3DX2,ou=3Dpeople,o=3DY,o=3Dgl=
uu. So it is possible to reference the person this information via =
several i-numbers.
>=20
> I think if we map back the i-names to i-numbers, in some cases this =
may make the examples more concrete.
>=20
> - Mike
>=20
>=20
>=20
> Let me note that this concept of "persona" is most commonly referred =
to in
> directory systems as a "role", i.e., =3Dalice has the +salesperson =
role at
> @company, and =3Dalice has the +pitcher role at @sports.club.
>=20
> The second pattern is where =3Dalice defines her own subcontexts that
> represent different personas.
>=20
> Now, what is unclear to me is why these two patterns differ one from =
another. Could we figure out any use case showing that a persona (second =
pattern) cannot be thought at as a role of an individual in an =
organization or group of members (first pattern)? I mean, from my PoV, =
+work, +baseball, +home, etc. are all "contexts" in which =3Dalice does =
play a "role": she is an employer in her "work context", a player in her =
"baseball (team) context" and a housewife in her "home context".
>=20
> Furthermore, to be precise, +work, +baseball, +home, are not proper =
instances of contexts, rather they are different "categories" of =
contexts; e.g. =3Dalice is a +driver in @example.bus.company, not in =
+work; she is a +player in @example.baseball.team, not in +baseball, she =
is +wife in @example.family, not in +home, etc. Finally she is herself =
in her default context, which is, simply, =3Dalice.
>=20
> A third thought is about the usage of "numbered subcontext": $1 ("the =
first", $2 ("the second"), $3 ("the third"), ... and $ (understood as =
"all of them") itself are OK when applied to an identifier which is, by =
itself, a group - I would say an array - i.e. an entity that naturally =
does contain members: =3Dalice+sister$1, =
@example.baseball.team+player$2, @example.bus.company+driver$, =
@example.family+member$, etc. However, this is less convincing when =
applied to identifiers identifying entities which are - per se - unique, =
such as =3Dalice.
>=20
> In other words, we should not have multiple =3Dalice, rather we should =
probably aim at having the very same =3Dalice playing, as you said, =
different roles in different contexts - or better - context instances.
>=20
> I might miss some important points here. If this is the case, please =
let me know - the ideal would be to have a use case for this - If not, =
then I think that this proposal is so simply that it could even =
succeed.. maybe.
>=20
> Best Regards,
> Giovanni
>=20
> Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:
>=20
> On Tue, Nov 16, 2010 at 12:50 PM, Giovanni Bartolomeo <
> giovanni.bartolomeo@uniroma2.it> wrote:
>=20
> In order to speedly proceed toward closing some issues:
>=20
>=20
> During the call we discussed two alternatives for identifying =
different
> personas, one is the currently adopted in PDX
>=20
>=20
> =
http://wiki.oasis-open.org/xdi/PdxExample#Pattern.3ASubjectSuperset.28Pers=
onaContext.29
>=20
> and the second is the one I proposed here:
>=20
>=20
> =
http://wiki.oasis-open.org/xdi/XdiOne/AddressingAndGraphModel#A.24has.24af=
orqualifyingcontexts
>=20
> my problem with the first option is that it causes semantic conflicts =
with
> the mereological interpretation of structured identifier (see =
hereafter
> reported excerpt from minutes):
>=20
>=20
> XDI adds a second feature to RDF, which is the ability of XRIs to =
express
> structured identifiers reflecting the merelogical structure of the =
graph,
> i.e., aggregation.
>=20
>=20
> that's why I'm in favour of the second one. However, I've understood =
that
> the first pattern has been introduced for some issues related to the =
XRI
> resolution process - which I'm a bit less familiar with. Could you =
maybe
> guys provide some more details on this issue?
>=20
>=20
> Giovanni, in preparation for today's call, let me explain that I don't =
think
> there is any conflict between the two patterns/models, i.e., that both =
work,
> and both are part of the way personas can/will be modeled in XDI.
>=20
> Let me first summarize the two patterns. The first one (illustrated in =
your
> second link above), is where an individual, say =3Dalice, can have =
different
> "personas" by being placed inside different supercontexts.
>=20
> @company=3Dalice
> @sports.club=3Dalice
>=20
> This pattern can be even more granular using tagged supercontexts.
>=20
> @company+salesperson=3Dalice
> @sports.club+pitcher=3Dalice
>=20
> Let me note that this concept of "persona" is most commonly referred =
to in
> directory systems as a "role", i.e., =3Dalice has the +salesperson =
role at
> @company, and =3Dalice has the +pitcher role at @sports.club.
>=20
> The second pattern is where =3Dalice defines her own subcontexts that
> represent different personas. This one is trickier, because =3Dalice =
can have
> many subcontexts, and not all those subcontexts represent personas of
> =3Dalice. For example:
>=20
> =3Dalice+tel =3D=3D> represents the collection of Alice's telephone =
numbers -
> not a persona of alice
> =3Dalice+friend =3D=3D> represents the collection of Alice's =
friends - not a
> persona of alice
>=20
> So the question is, how can =3Dalice define the set of personas for =
which she
> is the sole authority, not inside other authorities (like @company or
> @sports.club)?
>=20
> The pattern for doing this (illustrated in your first link above) is =
the
> inheritance pattern, i.e., defining subcontexts of =3Dalice that are =
by
> definition instances of =3Dalice. Following the metagraph symbol =
proposal,
> this uses the superclass/subclass operator, !. It also uses the =
subject
> operator, $, to indicate that the subcontext is a new subject.
>=20
> In this pattern (illustrated using i-names instead of i-numbers for
> readability), =3Dalice can create subcontexts that semantically assert =
they
> are personas because they are each subclasses of =3Dalice. Each of =
these
> personas is identified as a numbered subcontext, e.g., $1, $2, $3, =
etc.
>=20
> The XDI statements that create these subcontexts are:
>=20
> =3Dalice/$1/$ =3D=3D> creates =3Dalice$1
> =3Dalice/$2/$ =3D=3D> creates =3Dalice$2
> =3Dalice/$3/$ =3D=3D> creates =3Dalice$3
>=20
> The XDI statements that asserts that these subcontexts are personas =
are:
>=20
> =3Dalice/!/=3Dalice$1
> =3Dalice/!/=3Dalice$2
> =3Dalice/!/=3Dalice$3
>=20
> Thus the semantics of =3Dalice$[digits] where [digit] is a placeholder =
for any
> number of digits is that it represents a persona of =3Dalice defined =
by
> =3Dalice.
>=20
> This doesn't yet answer the question of how =3Dalice can identicate =
what type
> of personas these represent, i.e., which one is her +home persona, her =
+work
> persona, etc. These can be done with other XDI statements:
>=20
> =3Dalice/+home/=3Dalice$1
> =3Dalice/+work/=3Dalice$2
> =3Dalice/+baseball/=3Dalice$3
>=20
> Talk to you shortly,
>=20
> =3DDrummond
>=20
>=20
>=20
>=20
> ----------------------------------------------------------------
> Invito da parte dell'Ateneo:
> Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
> tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata
> codice fiscale: 80213750583 http://5x1000.uniroma2.it
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>=20
>=20
>=20
> ----------------------------------------------------------------
> Invito da parte dell'Ateneo:
> Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
> tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata
> codice fiscale: 80213750583 http://5x1000.uniroma2.it
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>=20
>=20
>=20
> ----------------------------------------------------------------
> Invito da parte dell'Ateneo:
> Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
> tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata
> codice fiscale: 80213750583 http://5x1000.uniroma2.it
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>=20
>=20
>=20
--Apple-Mail-248--1052465128
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Agreed.<div><br></div><div>If the common use cases are not easily understandable by unsophisticated developers, then adoption will not happen.</div><div><br></div><div>Remember XDI is competing against key value pairs (claims) and people have a hard enough time with that.</div><div><br></div><div>We skipped over simple Authority Type Instance, and dove into the deep end of RDF.</div><div><br></div><div>It has a certain elegance, but if this group can decide on statement equivalence etc then what chance will normal developers have?</div><div><br></div><div>Shipping code always beats the stuff that never makes it out of the labs.</div><div><br></div><div>John B.<br><div><div>On 2010-11-25, at 5:03 PM, Markus Sabadello wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I agree with both Mike and Giovanni. :)<br>
<br>
It is seducing to embark on a Faustian quest to build the
ultimate semantic reasoning monster that can do everything from
implementing whatever is the latest and hottest logical calculus, to
finding the very essence of life and making all the semantic web
utopists pee in their pants. How realistic this is in the face of
armies of PhDs that have tried it with RDF, I am not sure about.<br>
<br>
So, if the goal is to make XDI useful and gain adoption quickly<br>--> Do what Mike says, concentrate on 99% of the practical use cases
(in other words, forget all the semantic stuff), write the specs in the
next 2-4 weeks, and be done with it.<br>
<br>
If the goal for XDI is to be a hobby that can keep us entertained for
the next few years, or to be a long-term marketing vehicle for other
projects<br>--> Just continue what we're doing now.<br>
<br>
Markus<br>-- <br>blog: <a href="http://danubechannel.com/";>http://danubechannel.com</a><br>phone: +43 664 3154848<br><br><div class="gmail_quote">On Thu, Nov 25, 2010 at 3:02 PM, Giovanni Bartolomeo <span dir="ltr"><<a href="mailto:giovanni.bartolomeo@uniroma2.it";>giovanni.bartolomeo@uniroma2.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello Mike,<br>
<br>
sorry to disagree with you.<br>
<br>
Unfortunately, in standards which involve semantics you cannot satisfy 80% of requirements, and ignore the remaining 20%, because the latter is likely to make fail the whole system: actually one single contradiction in a semantic model is enough to invalidate all your reasonings.<br>
<br>
Please take a look at this message from Bill:<br>
<br>
<a href="http://lists.oasis-open.org/archives/xdi/201008/msg00022.html"; target="_blank">http://lists.oasis-open.org/archives/xdi/201008/msg00022.html</a><br>
<br>
which explains in an easy way why semantic matters are so essential to answer the question "What is XDI good for?"<div><div></div><div class="h5"><br>
<br>
Best Regards,<br>
Giovanni<br>
<br>
Def. Quota "Michael Schwartz" <<a href="mailto:mike@gluu.org"; target="_blank">mike@gluu.org</a>>:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'd rather be good than perfect here.<br>
<br>
I think we should support the easiest use cases, and we will probably end up satisifying 80% of the requirements. If we fail to get out a standard, we will satisify 0% of the requirements.<br>
<br>
If we are going to get these standards out, I suggest we take the path of least resistence on these symantic questions. What are the real world requirements to support these semantics? Let's focus on the semantic problems have the most real world applications.<br>
<br>
This will help XDI address its biggest marketing challenge: What is XDI good for? I think we need a new "get to market" approach, or we will never get to the finish line.<br>
<br>
- Mike<br>
<br>
<br>
<br>
<br>
--------------------------------------------------------------------------------------<br>
<br>
Michael Schwartz<br>
Gluu<br>
Founder, CEO<br>
<a href="https://www.gluu.org/"; target="_blank">https://www.gluu.org</a><br>
<br>
<br>
<br>
On Wed, 24 Nov 2010, Giovanni Bartolomeo wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Mike, Bill,<br>
<br>
Thak you Mike for disclosing this. Here is what's my problem about approach (see also last week's minutes here: <a href="http://lists.oasis-open.org/archives/xdi/201011/msg00023.html"; target="_blank">http://lists.oasis-open.org/archives/xdi/201011/msg00023.html</a>, bullet #3)<br>
<br>
+work, +home, etc., semantically, are not properly attributes of a person - even if it, for reasons related to specific programming environment constraints, they could be implemented as such.<br>
<br>
However, it has extremely complex implications to interpret them as "part of" a person in the widest sense it could be possible to interpret it without violating the mereological principle I was referring in my previous email (assumed we all agree on it).<br>
<br>
As Bill says:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
perhaps a better way of translating it might be thinking of +work as actually<br>
+worker, and +home as +resident.<br>
</blockquote>
<br>
this is something I like better, as it shifts the perspective from +work, +home to be attribute to a PoV which considers them as "qualities" of a person (not attributes), i.e. alice qua +worker, alice qua +resident, etc. This is better modeled using the generalization pattern, not the aggregation pattern.<br>
<br>
For example, in OO programming, once defined =alice as an object inheriting from both classes +worker and +resident, =alice inherits different (proper) attributes belonging to these classes, e.g. she may have two different telephone numbers (one for work and one for home), two different addresses (one for work and one for home), and so on.<br>
<br>
This is what I would exactly express with @example.bus.company+worker=alice and @NYC+resident=alice.<br>
<br>
Note that in former times, we used to say that @example.bus.company+worker=alice/$is$a/=alice and @NYC+resident=alice/$is$a/=alice, two statements that just remark the inheritance pattern above mentioned.<br>
<br>
Also, this makes it easier and clearer to refer to the same attributes in different contexts, e.g. @example.bus.company+worker=alice+address is (may be) different than @NYC+resident=alice+address. Note the similarity with e.g. Java: ((Worker)alice).address and ((Resident)alice).addres<br>
<br>
What do you think?<br>
<br>
Best Regards,<br>
Giovanni<br>
<br>
<br>
<br>
Def. Quota "Michael Schwartz" <<a href="mailto:mike@gluu.org"; target="_blank">mike@gluu.org</a>>:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Maybe I can shed some light on Gluu's implementation, and this could provide a concrete example.<br>
<br>
This first kind of role Drummond is referencing is either an attribute of the person, in which case no special consideration needs to be given: it can be handled as any other attribute. Or its represented as a group. At Gluu, the organization, the person and the group all have i-numbers in our directory service. And the groupMembership is also referenced in the memberOf attribute of the person (so again, group membership basically looks like an attribute of the person).<br>
<br>
Personas at Gluu are represented as sub-entries of the person. For example: inum=X1,ou=people,o=Y,o=gluu, where X1 is the inumber of the person and Y is the i-number of the organization. A person would be inum=z1,ou=personas,inum-X1,ou=people,o=Y,o=gluu. Furthermore, if we have a new person, X2, who is friends with X1, he may have a contact: inum=z2,ou=contacts,inum=X2,ou=people,o=Y,o=gluu. So it is possible to reference the person this information via several i-numbers.<br>
<br>
I think if we map back the i-names to i-numbers, in some cases this may make the examples more concrete.<br>
<br>
- Mike<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Let me note that this concept of "persona" is most commonly referred to in<br>
directory systems as a "role", i.e., =alice has the +salesperson role at<br>
@company, and =alice has the +pitcher role at @sports.club.<br>
<br>
The second pattern is where =alice defines her own subcontexts that<br>
represent different personas.<br>
</blockquote>
<br>
Now, what is unclear to me is why these two patterns differ one from another. Could we figure out any use case showing that a persona (second pattern) cannot be thought at as a role of an individual in an organization or group of members (first pattern)? I mean, from my PoV, +work, +baseball, +home, etc. are all "contexts" in which =alice does play a "role": she is an employer in her "work context", a player in her "baseball (team) context" and a housewife in her "home context".<br>
<br>
Furthermore, to be precise, +work, +baseball, +home, are not proper instances of contexts, rather they are different "categories" of contexts; e.g. =alice is a +driver in @example.bus.company, not in +work; she is a +player in @example.baseball.team, not in +baseball, she is +wife in @example.family, not in +home, etc. Finally she is herself in her default context, which is, simply, =alice.<br>
<br>
A third thought is about the usage of "numbered subcontext": $1 ("the first", $2 ("the second"), $3 ("the third"), ... and $ (understood as "all of them") itself are OK when applied to an identifier which is, by itself, a group - I would say an array - i.e. an entity that naturally does contain members: =alice+sister$1, @example.baseball.team+player$2, @example.bus.company+driver$, @example.family+member$, etc. However, this is less convincing when applied to identifiers identifying entities which are - per se - unique, such as =alice.<br>
<br>
In other words, we should not have multiple =alice, rather we should probably aim at having the very same =alice playing, as you said, different roles in different contexts - or better - context instances.<br>
<br>
I might miss some important points here. If this is the case, please let me know - the ideal would be to have a use case for this - If not, then I think that this proposal is so simply that it could even succeed.. maybe.<br>
<br>
Best Regards,<br>
Giovanni<br>
<br>
Def. Quota "Drummond Reed" <<a href="mailto:drummond.reed@xdi.org"; target="_blank">drummond.reed@xdi.org</a>>:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Nov 16, 2010 at 12:50 PM, Giovanni Bartolomeo <<br>
<a href="mailto:giovanni.bartolomeo@uniroma2.it"; target="_blank">giovanni.bartolomeo@uniroma2.it</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In order to speedly proceed toward closing some issues:<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
During the call we discussed two alternatives for identifying different<br>
personas, one is the currently adopted in PDX<br>
<br>
<br>
<a href="http://wiki.oasis-open.org/xdi/PdxExample#Pattern.3ASubjectSuperset.28PersonaContext.29"; target="_blank">http://wiki.oasis-open.org/xdi/PdxExample#Pattern.3ASubjectSuperset.28PersonaContext.29</a><br>
<br>
and the second is the one I proposed here:<br>
<br>
<br>
<a href="http://wiki.oasis-open.org/xdi/XdiOne/AddressingAndGraphModel#A.24has.24aforqualifyingcontexts"; target="_blank">http://wiki.oasis-open.org/xdi/XdiOne/AddressingAndGraphModel#A.24has.24aforqualifyingcontexts</a><br>
<br>
my problem with the first option is that it causes semantic conflicts with<br>
the mereological interpretation of structured identifier (see hereafter<br>
reported excerpt from minutes):<br>
<br>
<br>
XDI adds a second feature to RDF, which is the ability of XRIs to express<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
structured identifiers reflecting the merelogical structure of the graph,<br>
i.e., aggregation.<br>
<br>
</blockquote>
<br>
that's why I'm in favour of the second one. However, I've understood that<br>
the first pattern has been introduced for some issues related to the XRI<br>
resolution process - which I'm a bit less familiar with. Could you maybe<br>
guys provide some more details on this issue?<br>
<br>
</blockquote>
<br>
Giovanni, in preparation for today's call, let me explain that I don't think<br>
there is any conflict between the two patterns/models, i.e., that both work,<br>
and both are part of the way personas can/will be modeled in XDI.<br>
<br>
Let me first summarize the two patterns. The first one (illustrated in your<br>
second link above), is where an individual, say =alice, can have different<br>
"personas" by being placed inside different supercontexts.<br>
<br>
@company=alice<br>
@sports.club=alice<br>
<br>
This pattern can be even more granular using tagged supercontexts.<br>
<br>
@company+salesperson=alice<br>
@sports.club+pitcher=alice<br>
<br>
Let me note that this concept of "persona" is most commonly referred to in<br>
directory systems as a "role", i.e., =alice has the +salesperson role at<br>
@company, and =alice has the +pitcher role at @sports.club.<br>
<br>
The second pattern is where =alice defines her own subcontexts that<br>
represent different personas. This one is trickier, because =alice can have<br>
many subcontexts, and not all those subcontexts represent personas of<br>
=alice. For example:<br>
<br>
=alice+tel ==> represents the collection of Alice's telephone numbers -<br>
not a persona of alice<br>
=alice+friend ==> represents the collection of Alice's friends - not a<br>
persona of alice<br>
<br>
So the question is, how can =alice define the set of personas for which she<br>
is the sole authority, not inside other authorities (like @company or<br>
@sports.club)?<br>
<br>
The pattern for doing this (illustrated in your first link above) is the<br>
inheritance pattern, i.e., defining subcontexts of =alice that are by<br>
definition instances of =alice. Following the metagraph symbol proposal,<br>
this uses the superclass/subclass operator, !. It also uses the subject<br>
operator, $, to indicate that the subcontext is a new subject.<br>
<br>
In this pattern (illustrated using i-names instead of i-numbers for<br>
readability), =alice can create subcontexts that semantically assert they<br>
are personas because they are each subclasses of =alice. Each of these<br>
personas is identified as a numbered subcontext, e.g., $1, $2, $3, etc.<br>
<br>
The XDI statements that create these subcontexts are:<br>
<br>
=alice/$1/$ ==> creates =alice$1<br>
=alice/$2/$ ==> creates =alice$2<br>
=alice/$3/$ ==> creates =alice$3<br>
<br>
The XDI statements that asserts that these subcontexts are personas are:<br>
<br>
=alice/!/=alice$1<br>
=alice/!/=alice$2<br>
=alice/!/=alice$3<br>
<br>
Thus the semantics of =alice$[digits] where [digit] is a placeholder for any<br>
number of digits is that it represents a persona of =alice defined by<br>
=alice.<br>
<br>
This doesn't yet answer the question of how =alice can identicate what type<br>
of personas these represent, i.e., which one is her +home persona, her +work<br>
persona, etc. These can be done with other XDI statements:<br>
<br>
=alice/+home/=alice$1<br>
=alice/+work/=alice$2<br>
=alice/+baseball/=alice$3<br>
<br>
Talk to you shortly,<br>
<br>
=Drummond<br>
<br>
</blockquote>
<br>
<br>
<br>
----------------------------------------------------------------<br>
Invito da parte dell'Ateneo:<br>
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del<br>
tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata<br>
codice fiscale: 80213750583 <a href="http://5x1000.uniroma2.it/"; target="_blank">http://5x1000.uniroma2.it</a><br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this mail list, you must leave the OASIS TC that<br>
generates this mail. Follow this link to all your TCs in OASIS at:<br>
<a href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php"; target="_blank">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a><br>
<br>
</blockquote>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this mail list, you must leave the OASIS TC that<br>
generates this mail. Follow this link to all your TCs in OASIS at:<br>
<a href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php"; target="_blank">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a><br>
</blockquote>
<br>
<br>
<br>
----------------------------------------------------------------<br>
Invito da parte dell'Ateneo:<br>
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del<br>
tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata<br>
codice fiscale: 80213750583 <a href="http://5x1000.uniroma2.it/"; target="_blank">http://5x1000.uniroma2.it</a><br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this mail list, you must leave the OASIS TC that<br>
generates this mail. Follow this link to all your TCs in OASIS at:<br>
<a href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php"; target="_blank">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a><br>
<br>
</blockquote>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this mail list, you must leave the OASIS TC that<br>
generates this mail. Follow this link to all your TCs in OASIS at:<br>
<a href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php"; target="_blank">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a><br>
</blockquote>
<br>
<br>
<br>
----------------------------------------------------------------<br>
Invito da parte dell'Ateneo:<br>
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del<br>
tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata<br>
codice fiscale: 80213750583 <a href="http://5x1000.uniroma2.it/"; target="_blank">http://5x1000.uniroma2.it</a><br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe from this mail list, you must leave the OASIS TC that<br>
generates this mail. Follow this link to all your TCs in OASIS at:<br>
<a href="https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php"; target="_blank">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php</a><br>
</div></div></blockquote></div><br><br clear="all"><br>
</blockquote></div><br></div></body></html>
--Apple-Mail-248--1052465128--
--Apple-Mail-249--1052465000
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw
ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU
T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp
YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm
aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk
bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9
Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8
k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd
NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB
+rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK
7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B
MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h
Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt
ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD
b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p
dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh
dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa
MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG
AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI
KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF
BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3
Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz
lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy
Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3
toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG
SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt
YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ
A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ
gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1
13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU
euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/
MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB
nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp
MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9
BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh
LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js
LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB
VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv
aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh
cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM
ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw
EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF
AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p
ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4
ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB
9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT
e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW
0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+
BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw
vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ
x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW
yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr
DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEx
MjYxNjAyMjdaMCMGCSqGSIb3DQEJBDEWBBQXIikR6w/g5vufiIoe/RuAUyiVajCBpAYJKwYBBAGC
NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC
AQB5M9gzCYgTxEbRzMVi9VLIczmHGVqwzRzbMwUNdDtCKNhaUqUQfpkkUvIdi6sD8hgfcxKXt+3p
fcv9bvmZPgYV/paai1G6Sp+98SNWLlhZ5HNRyaMEsBcBR1KAqkcCxgiqT+bAvc2vsRoWJt14gYS9
m2SYCbgVSaaQkxuayqPoTrPDE1zTJt4TI+caIQd+d5O3QKePsufmOiFCnX4gFcff9S9kG2GD8urc
uw0NPIzwKYtJ5kJsga1quFW2wpuHkpc66kHKoqr8+F3JYGA7oZxilZMuIIkO2kozepWARVgwoCxn
Bi1Xbs0K06uhrS3k87NUduVmT56karyK4huVe2YYAAAAAAAA
--Apple-Mail-249--1052465000--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]