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


Dear Bill,

thanks for this mail. There are many issues involved and it is not 
easy to discuss them using email (maybe we should keep track of 
issues in the wiki). However I've tried to provide some first 
comments below (prefixed by G:).

Kind Regards,
Giovanni

on Sat, 28 Feb 2009 at 04:00:32 -0500  Barnhill, William wrote:
 >>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 ?).

G: I do not disagree with this (apart from the notation: $member). 
But, to me, being referenced doesn't mean necessary "being an instance of".

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

G: Simply I mean that =giovanni and =markus are digital subjects 
whose have been assigned the XRIs =giovanni and =markus. As such, 
they are in the global XDI graph, rooted in "=". The fact that they 
are referenced by =drummond/+friend is irrelevant to the fact that 
they exist (but obviously they are happy to be referenced by that 
predicate :-).

 >>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).

G: I probably do not understand this. I think that it is perfectly 
possible for an individual existing in the graph without being 
instance of +friend or +relative, etc. the minimum requirement is 
just to be an individual. Maybe I'm missing something here?

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

G: I almost agree with your first statement, predicates should be 
limited to "$" words or "+" words or variables $$. I do not 
understand the second one very well.

$ 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 ).

G: if you mean that any resource in XDI is considered an XDI:Entity 
then I agree. The conclusion that XDI:Entity are classified into 
individuals and communities makes some sense to me (but we probably 
need to discuss a bit more on this)

 >>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).

G: Since I'm working on this topic as well, it would be useful for me 
if we could discuss together this document. Can we coordinate in 
order to have a phone call or a chat on this?

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

G: Interestingly, can you report a bit more on this?

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

G: I think that the "instance" you are referring here is not 
=Drummond, instance of the individual class ("="), but 
=Bill.Barnhill+Friend=Drummond, an instance of =Bill.Barnhill+Friend 
class (which could be in turn an instance of +Friend). Consider this example:

+Friend/$has/+since

=Bill.Barnhill+Friend=Drummond/+since/"02-10-1998" (i.e. the 
individual =Drummond, casted to +Friend, in the context of 
=Bill.Barnhill, has the property +since - which is obviously 
context-dependent, i.e. changes with the context, 
=Bill.Barnhill+Friend=Giovanni/+since/"05-03-2007")

But would =Drummond/+since/"02-10-1998" or 
=Drummond/+since/"05-03-2007" make any sense?

Another way to say this is that =Drummond would exist even without 
being a friend of mine, or a friend of anyone. It exists because it 
is an instance of the individual class ("=").

The issue is whether =Bill.Barnhill+Friend=Drummond and =Drummond 
should point to the same XDI resource, e.g. whether 
=Bill.Barnhill+Friend=Drummond/$is/=Drummond or 
=Bill.Barnhill+Friend=Drummond/$is$a/=Drummond (as the implication 
suggested by Drummond +x/$has/+y --> +x+y/$is$a/+y would suggest). 
Probably we need to elaborate a bit more on this.

 >>I haven't thought of an example where the second restriction is 
not going to apply anyway.

G: see my example above

 >>In the case of @example/+Dept/*telecom anything other than that 
*telecom is an instance of +Dept seems counter-intuitive to me.

G: Please consider that this is a different case than 
=Bill.Barnhill/+Friend/=Drummond. @example-university/+dept/*telecom 
is actually describing a composition (@example-university is made of 
+dept of *telecom, +dept of *science, etc.), thus *telecom is an 
instance of +dept by definition. We used the lcs "*" to remark this.




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