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

Re: plural vs singular properties (a proposal)

From: Garret Wilson <garret@globalmentor.com>
Date: Thu, 18 Oct 2007 17:53:28 -0200
Message-ID: <4717B9B8.2070909@globalmentor.com>
To: Bruce D'Arcus <bdarcus@gmail.com>
CC: Sandro Hawke <sandro@w3.org>, semantic-web@w3.org


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?

That's certainly a valid issue, but in the real world I don't think it 
will cause many problems. I believe that in the most common use cases, 
the data that needs to be ordered will be presented at the same 
time---ordering usually relates values, so ordered properties will 
usually be presented together.

If it is the case that two data sets with ordered properties are merged 
(e.g. ordered ex:lastName from data set one, ordered ex:lastName from 
data set two), there are multiple ways to handle it. Even the naive way 
of ignoring order and merging properties doesn't wind up with too bad of 
a solution: the ordered properties are still in order *relative to each 
other*, although (via duplicated scoped order properties) they are 
intermingled with the other ordered properties. In other words, merging 
orders [0, 1, 2] and [0, 1, 2] produces orders [0, 0, 1, 1, 2, 2].

A more thoughtful merging would simply advance the order values of one 
of the sets so that the properties remain with the same relative order, 
but simply one ordered property set comes after the other. That is, 
merging orders [0, 1, 2] and [0, 1, 2] produces orders [0, 1, 2, 3, 4, 5].

Each of these scenarios I can easily live with. However, if you want to 
merge two values that are rdf:Lists, don't you wind up with the same 
issues? Sure, you can naively add properties and have one list of [A, 
B], another of [C], another of [D], another of [E, F, G]. That seems 
bulkier to me, though.


> E.g. the unordered nature of RDF is not some dumb hack, but a design 
> feature.

Just to be clear---I don't think the unordered nature of RDF is a dumb 
hack, either. But it has some shortcomings, as I've pointed out.

>
> We've argued about this before, but to summarize, I think your way of 
> describing this problem is a function of your programming background

It's possible. But you make it sound like that's a bad thing. :)


> and does not reflect real world name usage.

Ah, that's a separate issue altogether. I'd beg to differ, but who can 
say who's right? No one has had the option in RDF, so of course no one 
is going to use it. ;) We'll have to wait and see how useful it proves 
to be. It doesn't cost anything to try URF. I have personally tried it, 
and I like it. :)

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

Fine. Maybe it's not a problem you have. This is a problem I've 
repeatedly had, and I'm happy now. It seemed to be a problem Sandro was 
having, too.

Best,

Garret
Received on Thursday, 18 October 2007 19:54:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:18 GMT