Re: N-ary relations, Claims vs Facts, and RDF's odd frame model

Thanks for your comments, Stefan!  I'll try to respond to some other
points later, perhaps after Christmas, but some quick items:


On Thu, 23 Dec 1999, Stefan Decker wrote:

> subclassOf is transitive -> non-final.

It's still flattenable.  Of course, it's O(n^2) in flattened relations
worst-case, but this is a tree we're talking about so it's more likely 
O(n lg n) which seems perfectly reasonable.


>  >It appears that the only way that the relation Q(x,y) can be
>  >declared in RDF is _physically_ within x's description. y cannot
>  >declare the relation. No one else can either.  Only x can.  Other
>  >than making the "abbreviated syntax" look pretty, I am at a loss
>  >as to why this is so.  It seems arbitrary and unneccessary.
>
> I don't get you here. RDF just allows Object-Attribute-Value
> Triples. In a concrete RDF description one can define anything.
> Also that Bill Clinton is married to Madonna.

Let's say that the Library of Congress's super-popular schema defined
husbandOf(hus,wife) but not wifeOf(wife,hus).  Now, in RDF Bill Clinton
can say that he is Madonna's husband:

	<rdf:description about="Bill" s:husbandOf="Madonna" />

...but, amazingly, Madonna cannot say that Bill is her husband.  

	<rdf:description about="Madonna" ....  oops!

Interestingly, we can do it with a big scary reification declaration of
course.  But anyway the surface reason for this oddity is not semantic;
it's *syntactic*. But I imagine the deeper reason for this misfeature is
due to a design philosophy that tries to look "object-oriented" (objects
with embedded property slots) a-la frames.  But it is just one little
example of how such a design philosophy can bite you.



[regarding SHOE Claims]
 
> This point was extensively discussed a few weeks ago on this list.
> RDF has here a even more flexible solutions: reification allows to
> make expressions about expressions, so one can say:
> 
> [[A -property->B]-claimedBy->C]

Sure, and RDF's reification is a nifty feature.  But I had meant something
else.  RDF and SHOE both have the same basic syntactical arrangement,
namely, objects declared, with relational statements declared within the
body of the object.  But for RDF the fact that the relational statement is
"within" the object body means something different than it does for SHOE.
For RDF it means that the object will fill the domain position of the
relational statement.  For SHOE it means that the object is the claimant
making that particular relational claim.  A short example.  If I want to
declare Bill and say he's Madonna's husband in RDF, I say:

	<rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"	
	     xmlns:s="http://www.w3c.org/husbandwifeschema/">

		<description about="http://www.whitehouse.gov/bill/">
			<s:husbandOf>
				http://www.music.org/madonna/"
			</s:husbandOf>
		</description>
	</rdf>

In a verbose form of SHOE I might say:

	<instance key="http://www.whitehouse.gov/bill/">

		<use-ontology id="husband-wife-ontology" version="1.0"
			prefix="hw" url="http://www.shoe.org/husband-wife/">

		<relation name="hw.husbandOf">
			<arg pos=1 value="http://www.whitehouse.gov/bill/">
			<arg pos=2 value="http://www.music.org/madonna/">
		</relation>
	</instance>

SHOE's <instance> tag is roughly the equivalent of RDF's <description>
tag. So an RDF agent parsing this discovers the statement that
http://www.whitehouse.gov/bill/ is the husbandOf
http://www.music.org/madonna/.  

In SHOE the agent discovers that http://www.whitehouse.gov/bill/ *claims*
that http://www.whitehouse.gov/bill/ is the husbandOf
http://www.music.org/madonna/.  (It's not required that the claimant also
fill an argument position in the relational statement -- it just happens
to be this way in this example).

That is, every statement in SHOE is automatically considered only
"claimed" by a clearly-defined claimant, where as everything in RDF
appears to be automatically considered a "fact" (even if it's a reified
statement!). It's a minor point, though one worth considering.  But I
don't want to get bogged down in it.  I brought it up only to show that
there are useful things that object-internalization (on a syntactic level)
can be used for instead of just attaching domain features; and RDF's
attachment to a given syntax has affected its semantics, which I think is
never a good idea.


>  >, is
>  >the need for "special" collection classes, with custom numbered
>  >relational values. With an n-ary approach this special case
>  >magically goes away.
> 
> Not really. And having relations with 1000 arguments is not really
> fun....

Not what I had meant.  You don't need 1000 arguments in a relational table
to do ordered collection classes.  You only need an integer data type.  
As in Contains(x,y,1), Contains(x,foo,2), etc.  And of course, you need
n-ary relations. :-)  I still think container classes are one of those
things that RDF needed to smooth out deficiencies due to the insistance on
a binary-relation, typeless model.



>  > In RDF you attach elements to containers
>  >with a custom infinite (!) of relations, so in RDF you'd attach an
>  >element X as the first item with the relation rdf:_1(container,X).
> 
> No, not a relation. Just a counter, witch is a relation argument
> in a general relation triple. This is even more flexible.
>
>  >In SHOE you just make some relation, say, "contains", and write
>  >contains(container,X,1).  No more need for infinite relational
>  >sets.  Bag, etc. just go away.  And why not?  After all, since
>  >infinite relational sets aren't exactly easy to implement as
>  >tables :-), an RDF agent is probably going to implement this stuff
>  >internally as contains(container,X,1) anyway!
> 
> It handled in RDF in exactly the same way....

I believe it is not.  To quote from the RDF spec: "There is a subset of
Properties corresponding to the ordinals (1,2,3,...) called Ord.  We refer
to the elements of Ord as RDF:_1, RDF:_2, RDF:_3, ..."  That is, the set
of Properties is, right off the bat, infinite in size.  One might insist
that Properties are data, but if you implement it that way, you're going
to get stuck with one gigantic table of triples {property,domain,range}.  
I think it's fair to assume that most implementations will deal with
Properties as relational tables. In which case RDF has defined an infinite
number of relational tables!  :-)  No doubt must implementers will instead
map RDF containers into 3-ary relations the way SHOE already explicitly
states it (something like Contains(x,y,1) rather than _1(x,y)).  Which
begs the question: why shouldn't RDF do this to begin with?  Slavish
attachment to binary relations isn't healthy. :-)



>  >RDF has made some n-ary stabs.  In Section 7.3 for example, the
>  >RDF Model and Syntax Specification made some suggestions about how
>  >to get around this deficiency.  Nonetheless, non-binary relations
>  >are guaranteed to be second-class citizens in the RDF semantics.
>  >While binary relations are first-class resources in RDF,
>  >"pseudo-n-ary" relations are odd structures which cannot be
>  >referenced by a resource.
> 
> They can by reification.

I don't think they can.  There is no reification of a pseudo-n-ary
relation in RDF which is referenced by a single instance of the Statement
class.  However, all reified binary relations can be so referenced.  
Under RDF's scheme, the pseudo-n-ary relations are not first-class
citizens of the model.  It's a hack.  (The traditional hack for binary
models.  But a hack).


> What do you mean by first order inheritance?

One that can be expressed in first-order logic.  Not IDO, for example.

Merry Christmas, Stefan!

Sean

Received on Thursday, 23 December 1999 23:11:43 UTC