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] More on +x/+y/+x+y


Title: RE: [xdi] More on +x/+y/+x+y

Re-reading this I had an additional thought.

We have already stated in XDI that a concept can be both a class and an instance in XDI, which adds the complexity that OWL version of XDI is not in OWL DL.  The XDI semantics of statement as identifier though change things a bit such that might not matter as much. The implications in that are something we need to explore more.

See "Note that relating two classes via owl:sameAs is a very different thing to relating them via owl:equivalentClass. The former says that the two objects are in fact the same, is actually an example of class as instance, and thus pushes the ontology out of OWL DL." and related text in http://www.w3.org/TR/owl-ref/.

So given that...how is an individual not also a class with cardinality of membership property restricted to 1? And if =markus and =giovanni are sub-classes of xdi:Individual (as well as instances) doesn't that solve the dilemma you posed Giovanni?

I know that it seems weird from an intuitive standpoint to have an individual be the class that exactly matches that individual, but it makes sense from a reasoning standpoint I think.  Is there any way in which an individual cannot also be a community (restricted to 1 member)? This changes our type hierarchy, but it's a change that makes sense even from a resolution standpoint. How is resolution done for =markus ..we go to our root community = first, which means = is a @. Follows that =Markus is a @ as well. It also means that the root object in the XDI type hierarchy is community (the @), which somehow seems very right from both a technical and philosphical point of view.

=Bill.Barnhill

-----Original Message-----
From: Giovanni Bartolomeo [mailto:giovanni.bartolomeo@uniroma2.it]
Sent: Thu 2/26/2009 7:05 AM
To: Drummond Reed
Cc: xdi@lists.oasis-open.org
Subject: Re: [xdi] More on +x/+y/+x+y

Hello Drummond,

Thank you for your mail. I've put my comments and questions below.
Obviously it is not easy, the deeper we go, the more questions raise.
Thus, sorry if this email is so long!

Thanks,
Giovanni

At 07.32 20/02/2009, Drummond Reed wrote:
>Based on our discussions on the telecon today, I want to return to the
>"+x/+y/+x+y dilemma" and propose a solution.
>
>The "dilemma", as Giovanni explains in his message below, is that if
>+x/$has/+y metagraph statements infer that both +x+y/$is$a/+y and
>+x/+y/+x+y, then every $has statement infers that a subclass of +y is also
>an instance of +y. As Giovanni's example goes:
>
>#1      =drummond/$has/+friend
>#2      =drummond/+friend/=drummond+friend      <-- inferred from #1 -->
>#3      =drummond/+friend/=giovanni
>#4      =drummond/+friend/=markus
>#5      =drummond+friend/$is$a/+friend  <-- inferred from #2 -->
>#6      =giovanni/$is$a/+friend <-- inferred from #3 -->
>#7      =markus/$is$a/+friend   <-- inferred from #4 -->
>
>Giovanni's concern, as I understand it, is whether =drummond+friend is an
>instance of +friend the same way =giovanni and =markus are.
>
>Based on today's discussion and the proposed "last subsegment wins" rule,
>the answer is that =drummond+friend is a subclass of +friend, while
>=giovanni and =markus are instances of +friend.
>All three --
>=drummond+friend, =giovanni, and =markus have $is$a relationships to
>+friend, but the first is a subclass and the latter two are instances.

I think that =giovanni and =markus are not instances of +friend. They
are instances of the "individual" class, i.e. class identified by the
equals symbol (=). More specifically they might be instances of the
subclass +people. 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 think that 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. Having the property
+friend range +people, then =giovanni and =markus are on the right
place. I think instead that it might be appropriate to talk about
=drummond+friend as a subclass of +friend.

>This can be generalized to anything. Here's another example:
>
>*bugs.bunny/$is$a/+animal
>*flipper/$is$a/+animal
>+lion/$is$a/+animal
>+sheep/$is$a/+animal

I agree with this, however I think we should clarify the meaning and
usage of * (and !). In fact in =drummond/+friend/=giovanni
=drummond/+friend references =giovanni and not *giovanni. This is
because =giovanni exists independently from being =drummong/+friend.
In other cases you may have "local" instances which exists only as
such: @uroma2/+dept/*computer.science, @uroma2/+dept/*telecom.
@uroma2+dept*computer.science and @uroma2+dept*telecom would not
exist without @uroma2. I think this is related to the difference
between "composition" and "aggregation". (I see that these concepts
had been originally assigned to the meta words $has and $has$a, but
with these latest findings, maybe we could revise a bit this?).
In general, I'm in favour of the chain pattern
instance-class-instance-class-instance-class:
@uroma2+dept*telecom+member=giovanni, etc. etc.

>Or, to use the inverse:
>
>+animal/$a/*bugs.bunny
>+animal/$a/*flipper
>+animal/$a/+rabbit
>+animal/$a/+dolphin
>
>The first two are instances of animals and the second two are subclasses of
>the class animal. There's no conflict in this - both the instances and the
>subclasses have $is$a relationships to +animal.
>
>It gets even more interesting - if you turn the last example into $has
>relationships, you get:
>
>*bugs.bunny/$has/+animal        -->     *bugs.bunny+animal
>*flipper/$has/+animal           -->     *flipper+animal
>+rabbit/$has/+animal            -->     +rabbit+animal
>+dolphin/$has/+animal           -->     +dolphin+animal
>
>These are all now classes of +animal. In English they would be expressed as:
>"Bugs Bunny animal", "Flipper animal", "rabbit animal", "dolphin animal".
>The first two "inherit" the qualities of the instance they name (young
>children often use this kind of speech logic.) This illustrates how
>instances can be used to create subclasses just like classes can be used to
>create subclasses.

Sorry, I think that I do not understand this.. what does
*flipper/$has/+animal mean?

>And the inverse is true too. Classes can be used to restrict instances.
>
>+car/$has/*monte.carlo          -->     +car*monte.carlo
>+city/$has/*monte.carlo         -->     +city*monte.carlo
>
>In the first case Monte Carlo is an instance of a car, and in the second it
>is an instance of a city.

I see this as an interesting possibility. We can use $has to
enumerate members of a class. And we can use $has to enumerate
*properties* of instances =drummond+friend, =drummond+home, which are
"classes" +friend +home etc., using then the pattern class-instance
to identify which one is the right instance, e.g.
=drummond+home*san.diego, =drummond+home*los.angeles or just using
the bang symbol "!", =drummond+home!1234.5678.9012 and
=drummond+home!9876.5432.2109 (in this case bang would be used as a
sort of "pointer to a local  memory cell", as in programming language).

> From all of these, my conclusion is that it is not a problem for +x/$has/+y
>to infer both +x+y/$is$a/+y and +x/+y/+x+y. The first expresses inheritance
>(subclassing)

This is probably true when +y is a class. Some other times might not:
what does +city*monte.carlo/$is$a/*monte.carlo mean? Since
*monte.carlo is an instance, in this statement it is not in the right
place, assuming that the meaning of $is$a is "subclass of" or "instance of".

>and the second expresses hierarchy -- in particular the
>machine-navigable hierarchy which is the key (literally) to XDI addressing.

I'm still not understanding this, sorry. I think that the only
assumption we can make is that +x+y is just a new (composite)
subject, born from the metagraph statement +x/$has/+y which describes
his internal composition. But, apart from this, +x+y is a subject as
+x and +y are, and do not have any particular need to be referenced
by +x/+y. Could you detail a bit more about which machine-navigable
hierarchy are you referring, and what's the requirement to have +x+y
as object of +x/+y?

>In terms of the question of defining, "What is the range of +y?", I think
>the answer is, "at least all the subclasses of +y". These do not need to be
>enumerated; they can all be expressed generically as +y/$a/$$+y. The rest of
>the range of +y -- all the instances which must be enumerated in some XDI
>dictionary definition of +y, can be expressed generically as +y/$a/$$.

But this means that the predicate +y has a "double" range, including
classes (all subclasses of +y) and instances (all instance of +y)?
Thus, considering the following RDF excerpt (describing a real
device, Samsung R-500):

<rdf:Description rdf:ID="HardwarePlatform">
<rdf:type
rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20020710#HardwarePlatform"/>
<prf:BitsPerPixel>16</prf:BitsPerPixel>
<rdf:Description/>

In XDI/RDF would be (omitting some statements for the sake of simpicity)
+HardwarePlatform/$has/+BitsPerPixel
+HardwarePlatform/+BitsPerPixel/+HardwarePlatform+BitsPerPixel
+HardwarePlatform/+BitsPerPixel/"16"

But wouldn't this "double" range for +BitsPerPixel create any
ambiguities with query and reasoners?

As another example, consider the following query: what should it
return, if =drummond+friend is among the objects of =drummond/+friend?

=markus
         +get
                 /
                         =drummond
                                 +friend
                                         $$
                         $$+age
                                 $lesser
                                         "32"




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