W3C home > Mailing lists > Public > semantic-web@w3.org > October 2007

Re: plural vs singular properties (a proposal)

From: Bruce D'Arcus <bdarcus@gmail.com>
Date: Thu, 18 Oct 2007 15:21:27 -0400
Message-ID: <4717B237.90504@gmail.com>
To: Garret Wilson <garret@globalmentor.com>
CC: Sandro Hawke <sandro@w3.org>, semantic-web@w3.org

Garret Wilson wrote:
> Bruce D'Arcus wrote:


>> Question: are the difficulties around these issues in RDF a
>> consequence of the open world assumption, and the need to be able to
>> merge statements from disparate graphs?  
> No, I don't think that's the core issue here. The issue is simply that 
> there are many types of relationships in the universe, whether it's open 
> or closed, that cannot easily be represented by RDF because RDF doesn't 
> allow properties to be ordered. Needing to order properties without 
> resorting to heavy list-list classes is a *very* common use-case. 

Right, but I'm not clear how you merge ordered lists? E.g. the unordered 
nature of RDF is not some dumb hack, but a design feature.

> Let me give a few examples. (The 99% and 1% should be understood as exemplary, 
> not as actual percentages.)
> * 99% of the people in the world have a single last name, or multiple 
> last names that can come in any order. 1% of the people have multiple 
> last names for which order of these names is important. Do we create an 
> ontology in which the ex:lastName property takes only a single string 
> value, or do we make every ex:lastName property take an rdf:List, just 
> so that 1% of the people can represent their names correctly? (Note that 
> the problem here is not the open world assumption---maybe we know 
> exactly who those 1% are, and what their names are.)

We've argued about this before, but to summarize, I think your way of 
describing this problem is a function of your programming background and 
does not reflect real world name usage.

I think I'll be content when SPARQL supports reasonable query of lists.


Received on Thursday, 18 October 2007 19:21:50 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:03 UTC