Sam, By "generic RDF/XML" I mean arbitrary, unconstrained RDF/XML. We started out trying to define a constrained RDF/XML for general use because we thought it would be easier to parse with standard XML technologies. However, we did not want to pay the price of defining this precisely, having a validator, etc. We soon found it was very hard to entice toolkits to generate RDF/XML that precisely fit our design. The closest we came was the so-called Abbreviated RDF/XML in Jena. There was no spec for that. I assume it's just supposed to be easier to read by humans. In the end we decided to abandon that approach and simply adopt the W3C RDF/XML spec.
However, as a legacy, that compact UI spec still used the constrained RDF/XML. However, we don't call it RDF. It's content type is application/xml. It just happens to also be valid RDF/XML but service providers are not allowed to use unconstrained RDF/XML. They have to generate precisely that format. We could even have written an XSD to describe the format. The goal was to make it easy to parse in browsers, i.e. not require full browser-based RDF parsers. Yes, it would have made sense to use JSON for this purpose since browsers can more easily parse that. However, as a general rule, we want to minimize the number of formats a service provider has to support. This XML format is a MUST. ___________________________________________________________________________ Arthur Ryman DE, PPM & Reporting Chief Architect IBM Software, Rational Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) From: Samuel Padgett/Durham/IBM@IBMUS To: Arthur Ryman <[email protected]> Cc: Adam Archer <[email protected]>, "[email protected]" <[email protected]>, [email protected], Randy Hudson/Raleigh/IBM@IBMUS Date: 08/23/2011 11:12 AM Subject: Re: [oslc-core] OSLC Compact representation, titles with markup Hi, Arthur. Thanks for the answers. It clears some things up for me. Arthur Ryman <[email protected]> wrote on 08/22/2011 04:40:25 PM: > I don't think problems using XPath are a valid reason to encode markup > since RDF/XML itselt is very difficult to process using XPath. At one > point we tried to define an OSLC-variant of RDF/XML that looked like > "normal" XML. However, we abandonned that and now require support for > generic RDF/XML. To make sure I understand: By generic RDF/XML, you are talking about what the spec calls "constrained RDF/XML" in Appendix B, right? [1] > The are many equivalent ways to represent a given set of triples in > RDF/XML. It would therefore be very problematic to use XPath, XSLT, or > XQuery to process RDF/XML. The safe way to process RDF/XML is to use an > RDF toolkit like Jena. This makes sense, and I agree. But for me it also raises a few questions: - Do we need a JSON Compact representation for consumers who don't use an RDF library? This is one of the few resources in OSLC that doesn't have a JSON representation, and it seems natural since so often the consumer here is a web client. - Should we define a "constrained RDF/XML" representation if our recommendation is to use an RDF toolkit anyway? JSON might be a reasonable alternative for those who don't want RDF/XML. Best Regards, Sam [1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_application_xml
