[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Thoughts in Modeling Personas in XDI
Hello Mike,
sorry to disagree with you.
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.
Please take a look at this message from Bill:
http://lists.oasis-open.org/archives/xdi/201008/msg00022.html
which explains in an easy way why semantic matters are so essential to
answer the question "What is XDI good for?"
Best Regards,
Giovanni
Def. Quota "Michael Schwartz" <mike@gluu.org>:
>
> I'd rather be good than perfect here.
>
> 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.
>
> 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.
>
> 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.
>
> - Mike
>
>
>
>
> --------------------------------------------------------------------------------------
>
> Michael Schwartz
> Gluu
> Founder, CEO
> https://www.gluu.org
>
>
>
> On Wed, 24 Nov 2010, Giovanni Bartolomeo wrote:
>
>> Hello Mike, Bill,
>>
>> 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)
>>
>> +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.
>>
>> 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).
>>
>> As Bill says:
>>
>>> perhaps a better way of translating it might be thinking of +work
>>> as actually
>>> +worker, and +home as +resident.
>>
>> 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.
>>
>> 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.
>>
>> This is what I would exactly express with
>> @example.bus.company+worker=alice and @NYC+resident=alice.
>>
>> 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.
>>
>> 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
>>
>> What do you think?
>>
>> Best Regards,
>> Giovanni
>>
>>
>>
>> Def. Quota "Michael Schwartz" <mike@gluu.org>:
>>
>>>
>>> Maybe I can shed some light on Gluu's implementation, and this
>>> could provide a concrete example.
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> I think if we map back the i-names to i-numbers, in some cases
>>> this may make the examples more concrete.
>>>
>>> - Mike
>>>
>>>
>>>
>>>>> Let me note that this concept of "persona" is most commonly
>>>>> referred to in
>>>>> directory systems as a "role", i.e., =alice has the +salesperson role at
>>>>> @company, and =alice has the +pitcher role at @sports.club.
>>>>>
>>>>> The second pattern is where =alice defines her own subcontexts that
>>>>> represent different personas.
>>>>
>>>> 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".
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Best Regards,
>>>> Giovanni
>>>>
>>>> Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:
>>>>
>>>>> On Tue, Nov 16, 2010 at 12:50 PM, Giovanni Bartolomeo <
>>>>> giovanni.bartolomeo@uniroma2.it> wrote:
>>>>>
>>>>>> In order to speedly proceed toward closing some issues:
>>>>>
>>>>>
>>>>>> During the call we discussed two alternatives for identifying different
>>>>>> personas, one is the currently adopted in PDX
>>>>>>
>>>>>>
>>>>>> http://wiki.oasis-open.org/xdi/PdxExample#Pattern.3ASubjectSuperset.28PersonaContext.29
>>>>>>
>>>>>> and the second is the one I proposed here:
>>>>>>
>>>>>>
>>>>>> http://wiki.oasis-open.org/xdi/XdiOne/AddressingAndGraphModel#A.24has.24aforqualifyingcontexts
>>>>>>
>>>>>> 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):
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> Let me first summarize the two patterns. The first one
>>>>> (illustrated in your
>>>>> second link above), is where an individual, say =alice, can have
>>>>> different
>>>>> "personas" by being placed inside different supercontexts.
>>>>>
>>>>> @company=alice
>>>>> @sports.club=alice
>>>>>
>>>>> This pattern can be even more granular using tagged supercontexts.
>>>>>
>>>>> @company+salesperson=alice
>>>>> @sports.club+pitcher=alice
>>>>>
>>>>> Let me note that this concept of "persona" is most commonly
>>>>> referred to in
>>>>> directory systems as a "role", i.e., =alice has the +salesperson role at
>>>>> @company, and =alice has the +pitcher role at @sports.club.
>>>>>
>>>>> The second pattern is where =alice defines her own subcontexts that
>>>>> represent different personas. This one is trickier, because
>>>>> =alice can have
>>>>> many subcontexts, and not all those subcontexts represent personas of
>>>>> =alice. For example:
>>>>>
>>>>> =alice+tel ==> represents the collection of Alice's telephone
>>>>> numbers -
>>>>> not a persona of alice
>>>>> =alice+friend ==> represents the collection of Alice's
>>>>> friends - not a
>>>>> persona of alice
>>>>>
>>>>> So the question is, how can =alice define the set of personas
>>>>> for which she
>>>>> is the sole authority, not inside other authorities (like @company or
>>>>> @sports.club)?
>>>>>
>>>>> The pattern for doing this (illustrated in your first link above) is the
>>>>> inheritance pattern, i.e., defining subcontexts of =alice that are by
>>>>> definition instances of =alice. 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.
>>>>>
>>>>> In this pattern (illustrated using i-names instead of i-numbers for
>>>>> readability), =alice can create subcontexts that semantically assert they
>>>>> are personas because they are each subclasses of =alice. Each of these
>>>>> personas is identified as a numbered subcontext, e.g., $1, $2, $3, etc.
>>>>>
>>>>> The XDI statements that create these subcontexts are:
>>>>>
>>>>> =alice/$1/$ ==> creates =alice$1
>>>>> =alice/$2/$ ==> creates =alice$2
>>>>> =alice/$3/$ ==> creates =alice$3
>>>>>
>>>>> The XDI statements that asserts that these subcontexts are personas are:
>>>>>
>>>>> =alice/!/=alice$1
>>>>> =alice/!/=alice$2
>>>>> =alice/!/=alice$3
>>>>>
>>>>> Thus the semantics of =alice$[digits] where [digit] is a
>>>>> placeholder for any
>>>>> number of digits is that it represents a persona of =alice defined by
>>>>> =alice.
>>>>>
>>>>> This doesn't yet answer the question of how =alice 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:
>>>>>
>>>>> =alice/+home/=alice$1
>>>>> =alice/+work/=alice$2
>>>>> =alice/+baseball/=alice$3
>>>>>
>>>>> Talk to you shortly,
>>>>>
>>>>> =Drummond
>>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>> ----------------------------------------------------------------
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]