Re: [xdi] Thoughts in Modeling Personas in XDI

[Drummond Reed <drummond.reed@xdi.org>]

+1 to Joseph's points. In fact they touch on one practical aspect of
getting out the 1.0 specs that deserves its own thread, so I'll write
a separate message about that shortly.

=Drummond

On Mon, Nov 29, 2010 at 6:02 PM, Joseph Boyle <boyle.joseph@gmail.com> wrote:
> I agree those are the best selling points and would vote against
> omitting them. But I think getting them right in a reasonable amount of time
> will take both accelerated effort from TC members and getting input from
> other Semantic Web folks. We need to plan and execute this, or the end
> result in adoption will be little better than if we simply dropped the
> semantic effort now.
> We need to triage which semantic issues must be gotten right in the
> initial spec, and which are relatively independent and can be addressed in
> later specs. For example, I'd guess a detailed taxonomy of equivalence
> predicates of various strengths would be in the latter; please correct me as
> necessary.
> On Nov 29, 2010, at 12:02 PM, Barnhill, William [USA] wrote:
>
>
> I understand the need to get to market quickly and how easy it is
> to perceive the pursuit of an accurate semantic model that can be
> interoperable with RDF/OWL as an Ivory Tower snipe hunt. Unfortunately that
> perception is in my opinion just plain wrong. I do not see the biggest
> selling point for XDI as "another way to link data", or "a better way to
> structure data".
>
> To me the biggest selling points, and the ones that will make (or break if
> we leave them out) XDI's success, are that XDI (a) builds on/simplifies the
> semantic web vision of the web; (b) links that vision with the Linked Open
> Data vision to provide a pragmatic semantic model; and (c) builds on the
> resulting model by adding new XDI concepts such as bi-directional linking,
> link contracts, and a baked in re-usable and extensible mereology.  These
> selling points all rely on an accurate semantic model. If that is not your
> vision of XDI then we have two very different visions of XDI.
>
> That said, based on further emails Markus the trend seems to
> be favoring your opinion. So what do you suggest? Are you suggesting what
> you had in your email: "forget all the semantic stuff"? It is a huge change
> and while I am strongly against it if the TC feels that is appropriate then
> that's the direction for the XDI TC going forward. I really would like
> consensus built on this from everyone on the TC before addressing any other
> point, or failing that as last resort I'll write a ballot for a TC vote. I
> think this would be a huge course correction, would toss away much of the
> work done in the last two years, and would impact everything we do going
> forward in a negative way.
>
> Bill
> ________________________________
> From: markus.sabadello@gmail.com [markus.sabadello@gmail.com] On Behalf Of
> Markus Sabadello [markus.sabadello@xdi.org]
> Sent: Thursday, November 25, 2010 3:03 PM
> To: Giovanni Bartolomeo
> Cc: Michael Schwartz; OASIS - XDI TC
> Subject: Re: [xdi] Thoughts in Modeling Personas in XDI
>
> I agree with both Mike and Giovanni. :)
>
> 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.
>
> 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.
>
> 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.
>
> Markus
> --
> blog: http://danubechannel.com
> phone: +43 664 3154848
>
> On Thu, Nov 25, 2010 at 3:02 PM, Giovanni
> Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote:
>>
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
>