Re: comparing XML and RDF data models

> Take the simplest atom of information, "There is a Person named John"
> In RDF, there is only one representation;  <Person name John>

_:abc
   a :Person ;
   :hasName "John" .

or treating names as individuals, allowing the possibility of modeling Juan and John as being the same name...

:John a :Name .
:John :hasTranslation "John"@en .
:John :refersTo _:abc .
:refersTo owl:inverseOf :hasName .
_:abc a :Person .







----- Original Message ----
From: Bijan Parsia <bparsia@cs.man.ac.uk>
To: Semantic Web <semantic-web@w3.org>
Sent: Wednesday, July 2, 2008 5:58:57 AM
Subject: Re: comparing XML and RDF data models


Tim! Thanks for taking up the challenge in a serious way.

On 2 Jul 2008, at 11:25, <tim.glover@bt.com> wrote:

> I think there is a valid observation to be made about XML and RDF or
> relational representations.
>
> Take the simplest atom of information, "There is a Person named John"
>
> In RDF, there is only one representation;
>
> <Person name John>
>
> In RDBMS there is only one representation
>
> Person
> |------|
> | name |
> |======|
> | John |
> |------|

John hasType Person.
John name "John"

I see type columns in RDBMSs all the time.

Now, you might want to say that this isn't an "obvious"  
representation, and I'd agree. But we need to be very careful about  
cherry picking examples that work well for RDF and not so well for  
XML without considering counterexamples. (Think about representing  
ordered collections :))

(In essence, it seems to me, this example picks on the idea that RDF  
has a class/object notion built in. That *is* a good affordance:
    http://clarkparsia.com/weblog/2006/09/17/the-svg-argument/
)

> With more complicated data, the possible XML representations vary in
> different ways, and increase exponentially w.r.t. the number of  
> atoms of
> information.

Do they really increase *exponentially*? How do you identify an atom  
of information?

>   To extract the data from the XML we have to know the
> detailed representation chosen. Saying we can UNION different queries
> misses the point - we still have to write 3 queries. Saying we can use
> transformations misses the point - we still have to write
> transformations.

Even if this is true for this example, I've given several (and Paul's  
given an in principle) where RDF has similar problems. It seems that  
at best XML would be polynomially better (which can be significant,  
obviously). In the SVG argument, I pointed out that if you are in a  
sweet spot for something, then that something often (but not always)  
wins.

> The issue here is that XML fails to abstract the data from the
> representation as effectively as RDF and RDBMS. In this sense, RDF and
> RDBMS are better data representations than XML.

I think this is the same as XML doesn't have a built in  
representational model. But consider representing the structure of a  
record..I suspect you'll have a *much* easier time in XML Consider  
shifting from an ordered to an unordered representation. Again, much  
easier in XML. (consider using lists vs. containers).

So, even if I accept this example, we need more to make the  
generalization work. In principle, we need to make sure we've not  
cherry picked.

(But, big kudos for making a sensible, rational attempt.)

Cheers,
Bijan.

Received on Thursday, 3 July 2008 18:49:22 UTC