The below does make more sense for what we need than creating a whole new, and "non-backward compatible" syntax. Actually I was hoping perhaps OWL/XML was precisely what you recommend, a specification for producing a more regular (and xslt'able) RDF/XML. And as someone who never uses turtle, N3, etc. (they just muddy the water for me) I agree that XML can be as human readable as any of the syntaxes, especially if you have an XML viewer such as the one provided by the XML plugin in Eclipse.
Of course we are actually using Jena/Java directly to output our "non-RDF" XML (we build an XML OWL model using SPARQL Constructs, traverse it to build a DOM and then serialize the DOM) so I'll have to investigate how to set these flags that you speak of to see if we can lean this process out by using xslt directly on our RDF/XML. Just too much technology to keep up on :-) Jeff Work: 314-232-1997 Cell: 636-448-5990 The OWL/XML serialization was fundamentally unnecessary IMHO. The real problem is not that RDF/XML is broken. The main problem is that many RDF/XML writers are not using it well. It is actually very well possible to have nicely parseable RDF/XML files that are XSLT friendly. We just switch off the various options that exist in the RDF/XML syntax and use only one of the many possibilities. The OWL API actually makes a very good job in this, as the resulting RDF/XML files are very readable even for humans. You will have much better chances convincing us (esp quickly) to do a more regular RDF/XML output that might actually meet your customer requirements without sacrificing breaking the RDF stack. -- You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=.
