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

["Drummond Reed" <drummond.reed@cordance.net>]

Giovanni and Nick,

These are all excellent points. See responses inline, but no need to respond
further if you don't want - I'm going to make this thread the topic of
tomorrow's telecon.

=Drummond 

> -----Original Message-----
> From: Giovanni Bartolomeo [mailto:giovanni.bartolomeo@uniroma2.it]
> Sent: Wednesday, March 11, 2009 3:32 AM
> To: Nick Nicholas
> Cc: OASIS - XDI TC
> 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?

I absolutely agree that you need the context. In other words, the +id
attribute of =drummond with the value "9876" only exists in the context of
@golf-club+member=drummond, and the the +id attribute of =drummond with the
value "1234" only exists in the context of @example-company+member=drummond.
The above statements don't say that.

> 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

Yes, this adds the context.

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

Agreed.

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

I have seen this pattern a number of times now and my feedback is: yes, it
ALSO works.

For a number of months after XDI RDF was first generated, this used to make
me uncomfortable that there would always be three ways for adding the
necessary context to XDI RDF statements:

1) Contextualizing the XDI RDF subject;
2) Contextualizing the XDI RDF predicate;
3) Both! To use your examples, this would look like:

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

After working with it for long enough, I became much more comfortable that
_all three ways work_ and there is no one right answer. All three provide
sufficient semantics for the statements to be precise, and with sufficient
dictionary support, I believe a semantic reasoner could prove that all three
approaches produce the same underlying statements. (We still need to show
that formally.)

Although it would of course be nice if there was only one way to do
everything, but once again I will use the analogy to natural language:
having multiple ways to make a statement is not a bad thing as long as they
can all be clearly understood. In other words, the price we pay for the
flexibility and adaptablity of XDI RDF is worth it as long as the end result
is semantic interoperability at a scale that's never been possible before.

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

Great. I'll put that on the agenda for the call, coming out next.

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

Agreed.

> >*But* that does not do away with reification: predications can still
> >be reified, and denote states of affairs, rather than objects of
> >predicates.

Yes.

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

Great example.

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

Yes, all of it does to me. I would generalize it to say that any reified
statement -- a statement about a context -- cannot be interpreted as
applying to any particular XDI subject, predicate, or object within that
context, but only to the entire context.

Hope that makes sense...

=Drummond