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

>The point is not whether *you* view source, it's that you *can* view the source if you'd like.
No-one was arguing that we should remove the capability, only make the source more human readable.

>Also, call it a personal aesthetic, but I absolutely despise the 
>HTML-ish practice of lumping everything into tag attributes. 

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. 

In XMI both styles are supported for simple types, though I've never seen a model using the embedded elements for them; I guess most people are used to HTML source.

>The original aims of the SW are unmet by anyone -- UML/XMI included. 
Agreed.

>However, mark my words: when the aims of the SW and OWL *are* met, it 
>will not be through business-oriented "solutions" built on UML.

This is too religious to argue with, so I won't try and predict the future.

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.

>Furthermore, I don't believe there is a disjuncture; XMI and RDF/XML serve entirely different purposes. 

The different purposes are, in part, the cause of the disjuncture. That there is an overlap from blogs->metadata->modelling languages is where the purposes cohabit, so you get people like me and you talking to each other.

>One of the main draws to RDF for me was the fact that every term is labeled and given a (hopefully) valid URI to describe it.

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. 

A unique ID mechanism is supported in XMI, hence my assertion that XMI can fully encode RDFS and OWL metamodels and instance data.

> !!! [in response to saying you need to resolve the type model to perform type aware processing]
and
>[The OMG's XMI encoding] obscures the difference between a literal value and a resource. 
> For instance:
>  <owns xmi:type="Car" licensePlate="BEX" color="brown">
>Do "Car," "BEX" or "brown" have associated URIs? 

If you are interested, read the XMI specs and you will find this is not the case.

The encoding of simple types as attributes (the string 'BEX'), literal values as attributes (by name, in a canonical order for collections), object references as nested elements, is unambiguous. You may have been confused to my comment that you need to resolve the metamodel to fully process the model - to know that the type 'Car' is a subtype of 'Vehicle', or to get their associated uids, or to be able to process 'green,brown' as equivalent to 'rgb(100,100,0),rgb(0,255,0)'. That doesn't mean that you have to do so in most cases. I have collapsed 'with blue and green eyes' to a single multivalued property  'with eyecolor (green, blue)' rather than 'having an eye that is (green, blue) in color, and an eye that is (green, blue) in color' in my example, which may have confused you.

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,')). 

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

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)- which to me moves away from the 80/20 point (and makes it seem odd to me that you would categorise HTML-like, XPath queriable encodings in the same class of obsfucation that base-64 encoded Word). With either encoding (RDF/XML or XMI), you can load it into an inference engine if you require that capability. But with XMI, mostly you don't have to. (There are some interesting XPath based blog stuff by Jon Udell <http://weblog.infoworld.com/udell/2005/02/16.html>; he's using XQuery, mainly based on the html content of //item/body in his RSS store- you can get away with that as it's canonicalised to be tree based, rather than the general RDF relational model). 

This means (for most queries) you don't have to put an RDF inference engine into your site, and can just use XSLT stylesheets. 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. If you need the sorts of inference supplied by RDF inference engines, then use something that gives you that; but I'd treat that as the 20% case not the 80%.


Pete

Received on Friday, 11 March 2005 12:14:07 UTC