W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2005

inconsistency: container members being resources and/or literals

From: Karsten Tolle <tolle@dbis.informatik.uni-frankfurt.de>
Date: Thu, 10 Feb 2005 08:59:42 +0100
Message-ID: <000701c50f46$8e452270$7ef2f6d9@HANNOVER>
To: "Www-Rdf-Interest@W3.Org" <www-rdf-interest@w3.org>
Cc: "Karsten @dbis Tolle" <tolle@dbis.informatik.uni-frankfurt.de>
Hi,

 

sorry, I could not manage to scan the entire archive if this issue has been 

raised before. So, in case it has been already discussed, please, send me the 

link to it.

 

During exploring the RDF recommendations I discovered an inconsistency 

for containers. While in RDF Schema (5.1) and in RDF Semantics (4.1) 

container members are defined to be resources only, we can read in the 

RDF Primer (4.1) that members can be either resources or literals. 

 

If the RDF Primer is right and members can be resources or literals 

( no rdfs:range defined for rdfs:member), we might have:

_:x rdf:type rdf:Seq

_:x rdf:_1 "test"

_:x rdf:_1 http://www.example.com

 

one could (I am not 100% sure about this) entail that "test" and 

http://www.example.com are equal. (I think this is at least one reason why 

literals are not used in Collections.)

 

If RDF Schema and RDF Semantics are right, we have the problem that it is 

very difficult to describe a set of literals or a mixture of literals and resources 

in RDF. 

 

I thought about how to solve this problem and came up with this first shots:



1) One could define another container type called rdf:Set, that can be used 

with two additional ContainerMembershipProperties e.g. rdf:setResourceMember 

and rdf:setLiteralMember, having the corresponding range definitions. The 

two new properties could be defined as sub properties of rdfs:member (with 

rdfs:member having no rdfs:range defined) and the ContainerMemberschipProperties 

can be defined as sub properties of rdf:setResourceMember.

With these one could build: 

_:x rdf:type rdf:Set 

_:x rdf:setLiteralMember "test"

_:x rdf:setLiteralMember "test"

_:x rdf:setResourceMember http://www.example.com

_:x rdf:setResourceMember http://www.example.com

 

As in mathematical sets, duplicates should be ignored, meaning the above set 

would have the two members "test" (being a literal) and http://www.example.com 

(being a resource). Entering further resources or literals to this rdf:Set would be 

very easy, because there is no need to figure out which rdf:_nnn is not yet used.



The drawback I see here is the creation of another way to describe a 

collection and another extension of the rdf vocabulary, which will increase confusion

and complexity.



 

2) A different way to solve the problem would be to define (as we have in XML) a

notion of well-formed and valid RDF. Beside solving this particular problem, I 

personally  think it could solve many more. 

A valid RDF container could be defined as a container where a single 

ContainerMembershipProperty is only used once. 

With this restriction given, there would be no entailment error and the rdf:member property 

could be defined without a range definition.

. but it would be difficult to figure out for robots or agents which rdf:_nn

is not used yet, in case they want to enter a new member to a container.



 

3) Using containers with restrictions, like the closed containers described by 

Graham Klyne in 

http://lists.w3.org/Archives/Public/www-rdf-logic/2003Nov/0021.html.

Here again entailment problems could not happen, since each

ContainerMembershipProperty can would be restricted to be used only once and

again the rdf:member property could be defined without a range definition.

. again for entering new members one would need to find not used rdf:_nn properties.

In addition we are here already in the OWL layer.

  

Karsten

Btw.: Happy Birthday to the RDF recommendations ... and sorry for sending an

inconsistency message right on this day.

___________________________________
Karsten Tolle
Received on Thursday, 10 February 2005 08:00:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:13 GMT