[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2009-02-26
(forgot to cc list)
>
On 11/03/2009, at 21:31, Giovanni Bartolomeo wrote:
Nice example! Somewhere in the background of this is too is the de
dicto/de re distinction. ("the President of the US is the Commander in
Chief of the Armed Forces" is always true"; but "Barack Obama is the
Commander in Chief of the Armed Forces" is only true so long as he is
the president, so you can't plug the instance into the role slot
universally, only while the instance is an instance of the role.)
I don't like $has and concatenation for these, because $has is very
very vague.
I think you're on the right track with @golf-club+member=drummond/
+id/"9876" ; the problem is, that says @golf-club+member/$has/
=drummond , and I'd be more comfortable with a direct @golf-club
+member/$is$a/=drummond implied. So @golf-club+member=drummond could
mean "Drummond qua member of golf club", but I think it's still open
to also mean things like "the Drummond who is the cousin of the golf
club member" --- because while the connection between golb club and
member is defined through "+member", the relation between member and
Drummond isn't.
I think qualification of the attribute is more promising. We already
allow +member+role (+member/$has/+role, +member/+role/+president), and
just as @golfclub+member is meaningful, so is @golfclub+member+role.
the elegance here is that the compound predicate, @golfclub+member
+role, still relates two individuals as we like, =drummond and
+player, without having to have multiple avatars of Drummond as @golf-
club+member=drummond --- and lack of clarity of how to relate
=drummond to @golf-club+member.
In the world being sketched here, predicates define classes; and those
classes can be predicated on themselves, forming new classes. I'd
rather keep the terms separate from the classes. While I like where
you were going with @golf-club+member=drummond, I think @golfclub
+member+role is clearer.
Extra complication in attributes of attributes: the resulting
predications are not true or false, because not all members of the
first class will have the same value for the second class. They just
define subclasses, which are true or false when instantiated. So:
=drummond/+eyecolor/+blue
=giovanni/+eyecolor/+brown
=drummond/$is$a/+human
=giovanni/$is$a/+human
+human/$has/+eyecolor
But we can't say
+human/+eyecolor/+blue
+human/+eyecolor/+brown
as general statements. Instead, there is a class of blue-eyed humans
and brown-eyed humans, who are subclasses of humans. Moreover, blue-
eyed humans are a subclass of blue-eyed entities. So:
+blue($is+eyecolor) : the class of all blue-eyed entities: all x such
that +blue/$is+eyecolor/x
$a+human : the class of all humans
(I still don't know how to combine them! Argh!)
So the graph is:
(+member) --$has--> (+role) : +member/$has/+role :
Instantiating both member and
role, =drummond/+role/+president, =drummond/+role/+player...
(@XRI) --$has--> (+member) : @XRI/$has/+member : @XRI/+member/
=drummond, @XRI/+member/=giovanni...
(@XRI+member) : All x such that @XRI/+member/x :
{=drummond, =giovanni...}
(@XRI+member) <--$is$a (+member)
(@XRI+member) --$has--> (+role) : XRI members have roles, though the
individual members and roles vary
(@XRI+member)+role : =drummond/(@XRI+member)+role/
+president
It is still true that =drummond/+role/+president, de re, I guess; but
+role is relational itself --- role of member; and this allows a graph
to be created that gets the member, and the subject of member, into
the graph.
Drummond, or someone who gets graphs better than me: could you draw a
graph to illustrate this? There must be one.
> 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
>
>
>
> ---------------------------------------------------------------------
> 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
____.____1____.____2____.____3____.____4____.____5____.____6____.____7__
When in doubt, skype:opoudjis, Dr Nick Nicholas,
--- DOUBT! opoudjis@optushome.com.au Link Affiliates,
(- me) http://www.opoudjis.net Melbourne, Australia
* * *
Kai san swqhkan t' akriba piota, DR opoudjis@optushome.com.au
kai san plhsiaze pia h wra tesseres, NICK http://www.opoudjis.net
ston erwta doqhkan eutuxeis. NICH Link Affiliates. skype:opoudjis
K.P.Kabafhs, _Duo Neoi, 23 Ews 24 Etwn_ OLAS *Ceci n'est pas
un .sig*
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]