Re: plural vs singular properties (a proposal)

Sampo,

I really appreciate the time you've taken to provide thoughtful 
criticism of URF. A few responses are below:

Sampo Syreeni wrote:
> 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.

If I understand your criticisms here (please let me know if I don't get 
them right), they boil down to two: A) Ordering as scoped/contextual 
properties are hard to store in some storage mechanisms such as a RDBMS, 
and B) The current URF specification does not fully specify scoped 
urf.order properties because it does not specify the outcome of a merge 
of such properties. Let me think about A) for a bit, and touch on B) here.

If the URF specification clearly defined the outcome of merging scoped 
urf.order properties, would that alleviate some of your reservations?

I will agree that the URF way of modeling ordered properties is not 
"perfect" insomuch as one can construct cases in which ambiguous data 
could be produced (e.g. merging). However, any modeling language, as 
separate from the universe being modeled, will have some 
simplifications---that's what makes it a model, after all. I think the 
crucial questions are: 1) Does it give added benefits over RDF? 2) Are 
its shortcomings no worse than RDF? and 3) Is it the most elegant 
solution that is both simple and useful? Now #3 is more a question of 
opinion (you can guess my opinion), but the answers to #1 and #2 will 
give us some hints.

First, does it give some benefits over RDF? I think the answer is 
yes---RDF doesn't allow order. URF allows order. I've already in other 
emails given several examples in which it is useful to have order 
information, so I think if the model allows you to express order, that's 
a benefit.

Second, are the shortcomings of URF's orderings no worse than RDF? Let's 
take an example to see. Here's a typical use of URF 
ordering---specifying the priority of telephone numbers. (I'll use the 
URF VCard ontology at <http://www.urf.name/vcard.turf>.)

|vcard|<http://urf.name/vcard>,
|example|<http://example.com/example>,
example.jdoe:
  vcard.tel=\«tel:+1-234-567-8910», «tel:+1-234-567-8911»\
;

That's no different that the following TURF longer syntax, which 
indicates the scoped order properties explicitly:

|urf|<http://urf.name/urf>,
|vcard|<http://urf.name/vcard>,
|example|<http://example.com/example>,
example.jdoe:
  vcard.tel=«tel:+1-234-567-8910»:
    urf.order~#0
  ;,
  vcard.tel=«tel:+1-234-567-8911»:
    urf.order~#1
  ;
;

(You can use <http://www.guiseframework.com/demo/urfprocess> to verify 
this.)

Now, ignoring URF for the moment, if I were to propose the following 
RDF/XML pattern, would anyone on this list complain? I doubt it---it's 
even one of the patterns advocated by RDF Primer 
<http://www.w3.org/TR/REC-rdf-syntax/#rdfvalue>:

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:exterms="http://www.example.org/terms/">
  <rdf:Description rdf:about="http://example.com/example#jdoe">
     <exterms:tel rdf:parseType="Resource">
       <rdf:value rdf:resource="tel:+1-234-567-8910"/>
       <exterms:priority rdf:datatype="&xsd;integer">0</exterms:priority>
     </exterms:tel>
     <exterms:tel rdf:parseType="Resource">
       <rdf:value rdf:resource="tel:+1-234-567-8911"/>
       <exterms:priority rdf:datatype="&xsd;integer">1</exterms:priority>
     </exterms:tel>
  </rdf:Description>
</rdf:RDF>

But wait---isn't this really the same thing that I'm doing in URF 
(although harder to pull off and really ugly in RDF)? The merging issue 
is still there. And talk about undefined semantics---read the semantics 
of rdf:value at <http://www.w3.org/TR/rdf-mt/#rdfValue>, which are 
"explained intuitively" (quoting the spec):

"Since the range of possible uses for rdf:value is so wide, it is 
difficult to give a precise statement which covers all the intended 
meanings or use cases. Users are cautioned, therefore, that the meaning 
of rdf:value may vary from application to application. In practice, the 
intended meaning is often clear from the context, but may be lost when 
graphs are merged or when conclusions are inferred."

And on top of that, we're using exterms:priority, which is some 
ontology-specific ordering mechanism---we don't even know where to start 
there, unless we know what ontology we're dealing with!

But here's the core of the question, "are the shortcomings of URF's 
orderings no worse than RDF?" Let's say that at the end of the day, 
after you do your merging, that you simply throw away all the scoped 
urf.order properties. What are you left with? You're left with simple 
unordered properties, like you'd get in RDF! (Note that you can't safely 
"throw away" contextual properties using the sanctioned RDF rdf:value 
pattern---you've created some new artificial sub-property with no 
well-defined semantics, after all.) In other words, if I just ripped out 
the urf.order in the TURF examples above, I get this:

|vcard|<http://urf.name/vcard>,
|example|<http://example.com/example>,
example.jdoe:
  vcard.tel=«tel:+1-234-567-8910»,
  vcard.tel=«tel:+1-234-567-8911»
;

What is that? That's exactly the same semantics that you have in Harry, 
Brian, and Norman's RDF VCard ontology at <http://www.w3.org/2006/vcard/ns>!

So at the end of the day URF gives you a convenient *transparent* 
ordering mechanism that is useful in the most common cases (i.e. those 
in which the ordered properties are specifies at the same time), is 
interoperable with unordered properties, and is no worse than RDF 
because you can ignore the order and effectively fall back to the RDF 
version! To me, that's elegant. If someone comes up with something more 
elegant, I'll switch to it.


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

But if you have something that is *so* sensitive to merging, something 
that often has multiple values, and/or somethingyou know that you're 
going to merge later, then you can always use urf.list and have the 
exact same thing. URF doesn't keep you from using lists if you want to. 
My point is that ordered properties is for those cases that most of the 
time the ordered properties values are all together and merging isn't an 
issue---or if it is, is benign. And ordring is for those cases that most 
of the time you only have one value, but you want to keep your options 
open. Like multiple telephone numbers---if I merge two address books, 
I'd rather maintain the relative order and have one or two numbers of 
ambiguous order than to have several lists of duplicated telephone 
numbers that would mean I have to do some sort of sub-merging later, 
with the same issues!

urf.List and ordered properties are two modeling techniques for two 
different types of problems. In some cases, urf.List is too 
heavy---that's why Harry, Brian, and Norman's RDF VCard doesn't even 
*allow* you to use lists for telephone numbers. In RDF, if you want to 
maintain order of telephone numbers using 
<http://www.w3.org/2006/vcard/ns>, what do you do? There's nothing you 
can do---the ontology doesn't even allow you to use a list for this 
property! In URF, there's no problem---you just order some of the 
properties using scoped urf.order. It works transparently, and at the 
end of the day, if everyone ignores your scoped urf.order properties, 
you're no worse than you are with the RDF version of the ontology.

Cheers,

Garret

Received on Friday, 19 October 2007 22:15:09 UTC