[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: Murali Mani <mani@C...>
  • To: Uche Ogbuji <uche.ogbuji@f...>
  • Date: Tue, 10 Apr 2001 13:57:54 -0700 (PDT)

relationship bases

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@f...               +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
>
>
>


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.