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


Hello Bill, Mike,

thank you for your feedback. As this is easier to answer I'll answer  
this first. Other answers will follow but this gives me the  
opportunity to talk about a basic principle I'm following - important  
to understand my proposed design choices.

In summary I agree with you Bill, but with different motivations than  
the ones you expressed. You said:

> The parent context of the ordinal would define the
> meaning of the ordinal.

I'm thinking at something simpler.

My principle is the following: in a composite context such as +a+b, +b  
is always intended as "part of" +a, according to the mereological  
meaning of supplementation pointed out by Bill some time ago.

This way we have a formal axiomatic background for the fundamental  
capability of XDI, i.e. composition of new subjects starting from  
existing ones.

Please check minutes of Thursday, 11 November 2010 available at  
http://lists.oasis-open.org/archives/xdi/201011/msg00012.html  
(point#1) as a reference for this discussion.

Here is some examples (actually three different use cases):

*  =alice+name --> alice's name: attribute "name" thought as "part of" =alice

*  @example.baseball.team+player --> example.baseball.team's players:  
the group of players thought as "part of" @example.baseball.team  
(NOTE: the group, not the players themselves)

*  @example.baseball.team+player=alice --> one member (=alice) of the  
aforementioned baseball team, i.e. =alice is "part of" the group of  
players which is in turns "part of" @example.baseball.team

*  etc.

Now, if this is the case, $1, $2, etc. could be uniformly thought as  
"accessor methods" to the "parts" which define a given context,  
provided someone has defined an order among the different parts of  
this context.

NOTE: a proposal from Drummond is that, if $1, $2 etc. are the  
accessor methods for the first, the second, etc. part, then $ is the  
"accessor methods" which identifies all of these parts. I have no  
strong opinion for this, but since it may be a nice feature my vote is  
+1.

What do you think?

Best Regards,
Giovanni

Def. Quota "Barnhill, William [USA]" <barnhill_william@bah.com>:

> On your third thought Giovanni you said:
>> 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.
>
> My thought on this is assuming the mapping between an ordinal
> role and the meanings of "the first member", "the second member".
> I think you had it right when you said $1 ("the first", $2 ("the second"),
> $3 ("the third"). The parent context of the ordinal would define the
> meaning of the ordinal. For example $1 has different meanings in the
> contexts of a collection of members that's a bag, one that's a set, and
> one that's an ordered list, and a collection of attributes. Given that then
> =alice$1 could be the first attribute defined by her persona according to
> some ordering. Maybe =alice$1 is the attribute she/he feels defines them the
> most. Instead maybe =alice$1 is the first (according to some ordering) of
> the personas Alice uses.
>
> What do you think about the above?
>
> Kind regards,
> Bill
>
> Kind regards,
>
> Bill
> ________________________________________
> From: Giovanni Bartolomeo [giovanni.bartolomeo@uniroma2.it]
> Sent: Tuesday, November 23, 2010 10:50 AM
> To: Drummond Reed; OASIS - XDI TC
> Subject: [xdi] Thoughts in Modeling Personas in XDI
>
> * * * IMPORTANT for XDI graph model specs: TC MEMBERS PLEASE READ * * *
>
> Hello Drummond,
>
> still thinking at a possible solution according to our findings of
> last week's call
> (http://lists.oasis-open.org/archives/xdi/201011/msg00023.html), I was
> asking myself some very basic questions.
>
> You said
>
>> 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+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.
>
> 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
>



----------------------------------------------------------------
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]