OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Thoughts in Modeling Personas in XDI



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
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]