W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2003

Re: typed containers in RDFS: suggestions about the "long range" problem

From: Yuzhong Qu <yzqu@seu.edu.cn>
Date: Wed, 16 Apr 2003 15:58:39 +0800
Message-ID: <003e01c303ed$fdb02da0$9c0b77ca@xobjects>
To: Francesco CannistrÓ <fracan@inwind.it>
Cc: <www-rdf-interest@w3.org>


Use owl:intersectionOf  two class descriptions: rdfs:Container and the restriction (complete modal),
Not just rdfs:subClassOf  the restriction(partial modal) .

Yuzhong Qu

----- Original Message ----- 
From: "Francesco CannistrÓ" <fracan@inwind.it>
To: "Brian McBride" <bwm@hplb.hpl.hp.com>; <www-rdf-interest@w3.org>
Sent: Tuesday, April 15, 2003 12:19 AM
Subject: Re: typed containers in RDFS: suggestions about the "long range" problem


You convinced me that, as far as the processor reads statements separatelly, when it reads a statement like {rdfs:member rdfs:range voc:Apple} it restricts the range  of rdfs:member  without considering its domain or binding directly this statement with the statement {rdfs:member rdfs:domain voc:BagOfApple}. so, the answer to my original question (whether the behaviour by me supposed added semanticis not covered by RDFS) is negative ... I don't not why I did not succeeded in seeing it before, it's qiute evident :-( 

I'm concerned that with ontology languages I can do many things. For example with OWL the long range problem could be approached as follows:

<owl:Class rdf:ID="BagOfApple">
   <rdfs:subClassOf >
         <owl:onProperty rdf:resource="TheRDFS_Namespace#member" />
         <owl:allValuesFrom rdf:resource="#Apple" />
   </rdfs:subClassOf >

<rdfs:Property rdf:ID="listApples">
   <rdfs:domain rdf:resource="#listApplesDOMAIN" />
   <rdfs:domain rdf:resource="#BagOfApple" />

NOTE: in all cases it would be better to assert the constraint, rather than for rdfs:member, for each of rdf:_n, but it is not possible.

However I think the problem should be approached in core RDFS.

Tnx for attention.


Received on Wednesday, 16 April 2003 03:57:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:41 UTC