OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 1. RDF - should a RDF document always have a RDF schema with it?? --

No.  You have a schema if you need it.  However, I should note that
schemas are a large part of the aspect of RDF that enables semantic
transparency.  Of course, there's not yet enough in RDF schemas for this
anyway...

> 2. Is it possible to constrain the range of a property to be a bag of
> values in RDF Schema?? - I see no example or mention of this.

No, and this is an example of the sort of inflexibility I was discussing
earlier.  Your only current recourse for this is an artificial application
of multiple inheritance.

> Regarding the question of N-ary relationships, I believe in the
following.
> Any comments are appreciated.
> I do not think I perfectly agree with the RDF recommendation in Section
> 7.3 when they say that they represent N-ary relations using rdf:value, and
> use another property (eg: Figure 14). I think this actually represents
> more a "unit" of measure as the spec points out. I think there is a subtle
> difference between this and n-ary relationships. In short I do not think -
> Mr. X weighs 160 pounds is a ternary relationship.

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