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] Minutes: XDI TC Telecon Thursday 1-2PM PT 2009-02-26


Title: RE: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2009-02-26

That there was an clearer typing relationship between predicate and object in XDI XRIs was one of the useful differences from RDF.  My thoughts on why are below, following a response to Giovanni's example of why he believes this should not be:
Giovanni said...
"Giovanni's first point was that what =giovanni and =markus represent in
statements...

      =drummond/+friend/=giovanni
      =drummond/+friend/=markus

...are not instances of +friend. They are instances of the "individual"
class, i.e. class identified by the equals symbol (=). What we can read from
the statements =drummond/+friend/=giovanni and =drummond/+friend/=markus is
simply that two instances of the individual class +people, namely =giovanni
and =markus, are referenced by =drummond/+friend."

I agree completely..but it makes total sense to me to add that =Drummond/+Friend is a sub-class of +Friend, meaning an individual  referenced by =Drummond/+Friend is also referenced by +Friend/$member (is this the right $ word to represent membership in a class, or is it $is or $has ?).

Giovanni also said...
"Actually =giovanni and =markus would exists also if they were not +friend, and if they were
instances of +friend this would be not possible."

I'm not sure what you mean by this Giovanni. If you mean that they are in the graph rooted at =Drummond because of the friend relationship and without that they would not be in the graph then I'd agree that they wouldn't be in =Drummond graph without it..but if there's no connection to =Drummond then they shouldn't be in the graph, right?

If you mean globally..how is it not possible for =Markus to exist in global graph regardless of whether =Markus is an instance of +Friend?  +Friend membership doesn't mean one Drummond's friends, or friends with everyone, it means you are the friend of someone (does not necessarily mean they are a friend of yours, unless we define it that way in the dictionary).

Our predicates as currently defined are not going to be individuals (@ or = global identifiers) (but see next para) and not going to be local identifiers.  That means they will either be $ words, $$ variables, or + word classes.

As a sidenote, @ identifiers could conceivably be used as a predicate to indicate shared membership in a community.  This has some interesing implications but has not been discussed on list yet and violates general usage in examples so far.  If you did this then by my reasoning =Bill.Barnhill/(@Oasis*TC*XDI)/=Drummond => [(@Oasis*TC*XDI)/$member/=Drummond (@Oasis*TC*XDI)/$member/=Bill.Barnhill], which makes sense.

$ words are fundamental properties in that they have a range of any resource, so all we can say about the class of the object is that it is a subClassOf either xdi:Community or xdi:Individual  (my terms, as in email before an XDI:Entity is either a community/collection or an individual, see owl:unionOf ).

We can not say anything about the class of the range for $$ variables except that it is a subClassOf XDI:Entity since XDI:Entity is the root class and all classes are subClasses of it (assumption here, that bit has not been discussed on the list yet, it in my doc to be posted).

That leaves + word concepts. If we are going with a +word can be used as both a class and as a property (which we have been in the examples), then the following statements are all valid:
=Bill.Barnhill/+Friend/=Drummond
=Bill.Barnhill/$is$a/+Friend
+Friend/$has$a/+Name

If that's the case then benefit of having an implicit range class be either an XDI:entity (in case of $ words and $$ variables) or the predicate as a class is that you reduce the complexity of the dictionary. The cost of doing this is a restriction that an object must be either an XDI:Entity (which is always will be) if the predicate is not a + word, and that the object must be an instance of the predicate as a class if predicate is a + word. I haven't thought of an example where the second restriction is not going to apply anyway. In the case of @example/+Dept/*telecom anything other than that *telecom is an instance of +Dept seems counter-intuitive to me.

But... what about an object that is also a + word, for example =Drummond/+Friend/+Resident(@US*NY) ?

In my opinion having this statement in a graph states there is at least one XDI:Entity in the class that is an intersection (owl:intersectionOf) of +Friend and +Resident(@US*NY) and =Drummond/+Friend.


=Bill.Barnhill



-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Fri 2/27/2009 4:13 AM
To: 'OASIS - XDI TC'
Subject: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2009-02-26

Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Thursday, 26 February 2009 USA
Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

Giovanni Bartolomeo
Mike Mell
John Bradley
Markus Sabadello
Drummond Reed
Nick Nicholas

REGRETS

Bill Barnhill (in England)


1) XDI MIME TYPE AND XDI CLIENT-SIDE PROCESSING

Part of our XDI Serialization spec is defining one or more MIME types for
XDI documents. This has some powerful uses for triggering client-side
processing in browser scenarios. We reviewed the new wiki page on this topic
at:

    http://wiki.oasis-open.org/xdi/XdiMimeType

Drummond ran through the scenarios listed there. Markus ran through the
final section detailing the MIME types already used in the XDI4J project.

John asked how the XDI client would know how to return the response to a
client. Drummond explained how it would happen with XDI - by resolving the
XRI of the "sender" (the website).

John then pointed out that the XDI request from the website could describe
that the response can be returned to the site any way the site would like
it: HTTP post, OpenID AX (attribute exchange), SAML, etc. There was
consensus this could make it more attractive to sites to adopt because it
meant fewer changes to their back-end systems.

John also noted the query must be open so that it can apply to any user.
This can be accomplished using $$ variables as Markus has demonstrated in
the XDI Query utility.

    http://graceland.parityinc.net/xdi-querier/XDIQuerier

We also noted that mechanism could even be used for authentication to the
site in a manner similar to information cards. We discussed how it could be
used directly in conjunction with information cards as a way to extend them.
The card essentially could serve as a security token wrapper around the XDI
messages.


2) $HAS SEMANTICS (MORE ON +X/+Y/+X+Y)

We started discussing Giovanni's message posted to:

    http://lists.oasis-open.org/archives/xdi/200902/msg00034.html

Giovanni's first point was that what =giovanni and =markus represent in
statements...

      =drummond/+friend/=giovanni
      =drummond/+friend/=markus

...are not instances of +friend. They are instances of the "individual"
class, i.e. class identified by the equals symbol (=). What we can read from
the statements =drummond/+friend/=giovanni and =drummond/+friend/=markus is
simply that two instances of the individual class +people, namely =giovanni
and =markus, are referenced by =drummond/+friend. Actually =giovanni and
=markus would exists also if they were not +friend, and if they were
instances of +friend this would be not possible.

There was consensus Giovanni was right: the predicate +y in +x/+y/=z does
not mean that =z is a +y

Giovanni gave the example @uroma2/+dept/*telecom. This is different than
=drummond/+friend/=giovanni because *telecom is not a global identifier. So
the * and ! generally identify local instances of a global class.

In general, Giovanni is in favour of the chain pattern
instance-class-instance-class-instance-class:
@uroma2+dept*telecom+member=giovanni, etc.

Drummond agreed that pattern works well - in RDF that same pattern is called
"striping".

John noted that this is really ATI (Authority/Type/Instance) under the hood
because chains authority/type/instance to create a new authority.


3) NEXT CALL

Thursday 3/5 1-2PM PT (21:00-22:00 UTC)


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