Re: plural vs singular properties (a proposal)

On 2007-10-18, Garret Wilson wrote:

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

I think a more serious problem is that you are using ordering as a 
vehicle for carrying many different kinds of semantics. For example, 
under an RDBMS, you'd be forced to model whatever the order carries 
using new columns, with an explicit domain, a name, clear definitions, 
constraints and normalization. This happens because only unordered sets 
are available for modeling, and it's an explicit design feature of the 
relational model.

Here the semantics aren't modelled exactly, because URF tries very hard 
to make things easy for you. But once you have to accomplish something a 
bit less trivial, like a merge, the irregularity caused by the extra 
structure, and the underspecification encouraged by it, suddenly show. 
You get alternatives, i.e. don't know exactly how you should merge and 
in any case do not have a canonical, interoperable means of doing so.

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

Usually this is far safer. Take your example with family names. You 
can't very well merge two "order-sensitive" ones, but you can certainly 
have two of them. So the next question is, doesn't URF in fact make it a 
bit too easy to use a structure which *forces* you to mix lists 
inappropriately upon a merge? I mean, this is a well-known complication 
with data models which permit structural recursion, like the nested 
relational one.
-- 
Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Received on Friday, 19 October 2007 10:22:01 UTC