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


I joined this list to be more familiar with the discussions here. It has
been quite interesting so far. I am a beginner in RDF (have read only the
specs), and I think I mostly will end up using it in sensor networks
scenarios. I first wanted to clarify a few beginner's questions, if
someone has the time:

1. RDF - should a RDF document always have a RDF schema with it?? --
I hope not -- RDF specializes tags and structure in such a way that we
do not need schema for getting to the semantics. What I am saying is we
know what are resources, what are their properties and what are the
property values without any schema. In stead, we need a schema only to do
some validation, also we get to know more about the resources and
properties like subtyping information. On the other hand, it is difficult
to make out much about an XML document unless we have a schema.
Note as a side note: I like very much the "property-centric" approach
of RDF Schema.

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.

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.

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.

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

thanks and regards - murali.

On Sat, 7 Apr 2001, Thomas B. Passin wrote:

> I'm totally with you here.  I think that N-ary relationships are important
> and need to be handled, and I'm not convinced that they can be properly
> handled by multiple binary associations.  Coming from a some modest
> baclground with Conceptual Graphs, some of the things I see in both RDF and
> Topic Maps just mystify me.  Things that seemed like they were simple and
> straightforward ended up obscured and complex, or at least unclearly
> defined, and in the name of What???  No doubt there were ***Good
> Reasons*** - there usually are, aren't there?
> Cheers,
> Tom P