Re: Linkbases, Topic Maps, and RDF Knowledge Bases -- help me

[Murali Mani <mani@CS.UCLA.EDU>]

Let me concentrate only on relationships, w/o special focus on RDF.
Regarding relationships: Binary relationships are quite easy --

1. Ordered 1:n binary relationships in XML schema -> using parent-child
2. Unordered n:1 relationships in XML schema -> using IDREF, we need IDREF
to identify the target type, somewhat similar to what DSD had in mind.
3. Ordered n:m relationships (ordering on one side) -> using IDREFS, if
IDREFS identify target type.
4. Unordered n:m relationships -> using what is done in the relational
model -> have one relation for each entity, and one relation for the
relationship and have some foreign key constraints.

Of these, 2 and 3 are not really supported in any schema language. Can we
hope for them?? - probably there should be a light weight schema language
that allows us to add such things more easily :)

Let us consider N-ary relationships (N > 2). Again there are two cases --
(a) one of the entities has cardinality of 1 (min of 0 and max of 1)
(b) all entities have maximum cardinality > 1

The general idea in relational model and object model for N-ary
relationship is to have a new object/type/relation for the relationship.

I think one common example of ternary relationship is the supplier kind of
relationship. It is something like (not very sure of the exact one)
m suppliers supply n products to p cities.

I think the following is allowed in ODMG:

class supply {
  relationship Supplier supplier;
  relationship Product product;
  relationship City city;
}

I made one statement about being theoretically able to represent a
N-ary relationship without creating a new type for the relationship. But I
think that is possible only if one of the entities have cardinality 1, and
is *not* possible otherwise. I think this can also be thought in terms of
representing multiple relationships, but I think the fact is it works.

<warning>speaking for himself only</warning>

cheers and regards - murali.

On Sun, 8 Apr 2001, Uche Ogbuji wrote:

> Certainly not every N-ary reltionship has to do with measure, or even
> general qualification, but I do think that units of measure and qualified
> arcs are N-ary relationships.
>
> Are you having difficulty seeing how RDF binary directed relationships can
> be combined to form N-ary relationships in general?
>
> > Rather a n-ary relationship can be represented in multiple ways in RDF
> > just like in a schema for XML -
> > have multiple properties: eg: <!ELEMENT book (author+, releaseDates+)>
> > I think the above can probably translated into RDF as a book resource with
> > two properties (both are bags or lists) -- author and releaseDate.
> > or you can represent in a "IDREF/(S)" way like
> > <!ELEMENT book (author::IDREFS->person+, releaseDates::IDREFS->date+)
> > I do not think any schema language actually supports the above as of now.
> > or you can represent them using foreign keys like in a DB.
> > I think the first two are fine with RDF, the latter one is not because we
> > need to explicitly specify these constraints.
>
> Hmm.  If I'm following you properly, you're talking about two different
> things: multiple relationships versus N-ary relationships.
>
> > Anyway, getting back to the question, I think representing a binary
> > relationship as multiple binary relations is not a bad idea, this is what
> > I think the ODMG model supports: create a new Class for the relationship,
> > and have n binary relationships specified.
>
> I think this confirms that you're mixing things up ODMG does *not* support
> the idea of N-ary relationships, except through systems that might fully
> expose the Metadata classes as first-class relationships.
>
> For example, 4ODS [1], an ODMG impleemntation for Python that I
> co-develop, does expose Relationship objects as metadata instances, but
> they do not have regular object IDs, so they cannot be used for modeling
> N-ary relationships.  ODMG implementations are not required to have OIDs
> for metadata instances, and I'd be surprised if there was an
> implementation that did.
>
> The fact that in RDF the relationship itself can be addressed using a
> "first-class" reference is what makes N-ary relationships possible.
>
> > Rather in RDF, in stead of
> > creating a new type for the relationship, you keep one resource as the
> > kind of "root", and specify relationships. I am quite sure this also
> > works.
>
> [1] http://www.4suite.org/4SuiteIndex.epy
>
> --
> Uche Ogbuji                               Principal Consultant
> uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
> Fourthought, Inc.                         http://Fourthought.com
> 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
> Software-engineering, knowledge-management, XML, CORBA, Linux, Python
>
>
>