Re: XMI vs RDF/XML (was: Style question)

On Mar 11, 2005, at 6:13 AM, Kirkham, Pete (UK) wrote:

> Given this was originally a discussion of 'style' with respect to an 
> XML encoding of models derived from a chatbot, and the prime aim was 
> replicating the growth of HTML through 'view source', we obviously 
> have different conclusions as to what is best in that regard.

I should have been more clear; it was a discussion of style with 
respect to RDF/XML, and the aim was replicating the growth of HTML for 
RDF/XML. :)

> Every time I start a new modelling project, I look at what's going on 
> in the SW world, and end up using  XML and UML based tools, as they 
> already solve my problems. These problems are a useful subset of those 
> the the SW effort addresses.

What problems are these? My main issue with XMI is that it doesn't seem 
to have any momentum for describing general-purpose metadata, so it 
doesn't hold much traction as a "standard" in my view.

> Either the URI is valid or not; if not, it's not RDF. It's no more 
> 'hopefully' valid than the XML is 'hopefully' well formed. (or do mean 
> resolvable? I don't think you will have much support arguing that 
> uuids must be resolvable.) RDF also supports blank nodes without an 
> URI.

I did mean to say "resolvable," which I know is controversial to some 
extent. However, although it's not a requirement of the RDF spec, I 
think it's good practice, and most examples of RDF out there use 
resolvable URIs far more than merely valid URIs. Furthermore, even 
non-resolvable URIs often give clues as to the meaning of the term 
(http://example.org/authors/diamond), which is enough to help human 
users.

Blank nodes are just a technical necessity for connecting sections of 
graph. You would never terminate a section of a graph in a blank node 
(or at least I can't think of a reason to do that), thus there's never 
a need to know what the blank node "means."

> As an example query on the model, the xpath 
> /Community/member/[@eyecolor='blue,green'] will result in people with 
> eyes that are green and blue, 
> /Community/member/[f:hasMember(@eyecolor, 'green')] in people that 
> have some green in their eyes (asuming you've defined a function 
> f:hasMember(x, y) := contains(concat(',',x,','),',y,')).

You can do many things with Xpath -- my point is that I'm not fond of 
XML that doesn't parse completely without additional help. RDF may  not 
always parse into the most understandable tree, but at least all the 
values are naturally discrete.

> Because XMI2 is a lot closer to being a canonical model, a very many 
> useful things can be done with XML technologies, rather that inference 
> engines (though you still need inference engines for other things).

Useful things like what? RDF/XMI must break the tree model as well if 
it can represent RDF fully. So what's the "real" difference?

> In RDF/XML encoded RDF, you need something other than xpath to query 
> your model (or you have to make a much more complicated query)

I don't know about *much* more complicated query.

> This means (for most queries) you don't have to put an RDF inference 
> engine into your site, and can just use XSLT stylesheets.

What prevents me from using XSLT with RDF/XML and/or using 
tree-structured RDF?

>  If you don't like it, don't use it - again, we could argue about 
> technology takeup. If in doubt, I'd do the simpler thing that is less 
> work.

The simpler thing that is less work is undeniably RDF/XML for me. I'm 
still unconvinced that adopting RDF-over-XMI is desirable in any way. 
But if it starts to see adoption on the scale of RSS and FOAF, I'll be 
sure to give it a second look.

- ben

Received on Friday, 11 March 2005 19:47:08 UTC