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


Hello Nick,

thank you for your useful help; yes that absolutely makes sense to 
me. +since should be properly an attribute of the fact 
(=Bill/+friend/=Drummond) rather than of the class +friend (I'm 
probably too biased from OO modeling ;-).

However, the issue I'm currently facing with is as follows: consider 
a relational predicate and its class, e.g. +member. Consider some 
attributes that refer to the class itself, e.g. +id, or +role. Now 
assume the following statements are asserted:

@golf-club/+member/=drummond
@example-company/+member/=drummond

following the suggested input ("Predicates in XDI have denotations: 
+friend as a class is the class of all objects of the predicate 
+friend.") =drummond, as object of the predicate +member, should then 
inherit the attributes +id and +role, thus should I be able to 
describe the following?

=drummond/+id/"9876"
=drummond/+role/+player
=drummond/+id/"1234"
=drummond/+role/+ceo

probably this makes some sense, but wouldn't it be more useful to 
have these attributes qualified, i.e. put in the right context?
One solution I'm thinking is

@golf-club+member=drummond/+id/"9876"
@golf-club+member=drummond/+role/+player
@example-company+member=drummond/+id/"1234"
@example-company+member=drummond/+role/+ceo

Note: @golf-club+member=drummond comes directly from the assertion 
@golf-club+member/$has/=drummond, which should make sense if we 
assume that $has can be used to describe the class extension.

Instead, a different solution could be to qualify the attribute (I 
don't have investigated this too much yet):

=drummond/@golf-club+member+id/"9876"
=drummond/@golf-club+member+role/+player
=drummond/@example-company+member+id/"1234"
=drummond/@example-company+member+role/+ceo

What do you think?

Giovanni

PS:I've still the AP to setup a wiki page on this topic, collecting 
inputs from replies to my mails. Hope to be able to do this before next phc...


At 01.01 10/03/2009, Nick Nicholas wrote:
>I will do an overview answer to this series of posts later on today I
>hope. It's unfair of me to zoom in on this post, because it's a
>digression to what Giovanni was saying (and I haven't grasped the
>point he was making yet); but:
>
>Predicates in XDI have denotations: +friend as a class is the class of
>all objects of the predicate +friend.
>
>*But* that does not do away with reification: predications can still
>be reified, and denote states of affairs, rather than objects of
>predicates.
>
>So:
>
>+friend is the class that includes {=Drummond}, because Drummond is a
>friend to someone.
>
>=Bill/+friend/=Drummond also has a denotation --- =Bill (if I'm not
>mistaken).
>
>But that does *not* mean you can plug =Bill anywhere you see =Bill/ 
>+friend/=Drummond . In particular:
>
>=John/+says/(=Bill/+friend/=Drummond) does not mean the same as 
>=John/ +says/=Bill
>
>
>Now, +friend is a predicate, and is inherently relational. But when
>used as an RDF subject or object (a term), it denotes individuals, not
>states of affairs. And it cannot be used in place of a state of affairs:
>
>(=Bill/+friend/=Drummond)/$is$a/+true-statement     makes sense
>=Bill/$is$a/+true-statement                         does not
>+friend/$is$a/+true-statement                       does not either
>
>because when it is a term, +friend is not anything different to =Bill:
>it is a class of individuals, and /$is$a/+true-statement only applies
>to states of affairs (reified predications). Similarly,
>
>(=Bill/+friend/=Drummond)/+since/2006               makes sense
>=Bill/+since/2006                                   does not
>+friend/+since/2006                                 does not either
>
>for the same reason.
>
>Hope that makes sense...
>
>On 06/03/2009, at 02:06, Giovanni Bartolomeo wrote:
>
>>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.
>
>--
>  Dr Nick Nicholas: Link Affiliates    opoudjis@optushome.com.au
>http://www.opoudjis.net                          skype:opoudjis
>   "Must I, then, be the only one to be beheaded now?" "Why, did you
>want
>everybody to be beheaded for your consolation?" Epictetus, Discourses
>1.1.
>
>
>
>
>---------------------------------------------------------------------
>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]