Dave, I think we need to seriously re-examine our goals for defining a "simplified" subset of RDF/XML for OSLC specs. The latest change to using <rdf:RDF> as the document root now invalidates one of the original goals of making the content look like "normal" XML. Now it is very clear that the document is RDF/XML. Also, since we are using the content type application/rdf+xml it seems wrong for OSLC to define restrictions on the format.
The intended benefit for restricting the format was that it would allow implementers to reuse their XML parsing skills and tools. However, we are already using most of the RDF/XML syntax so writing an XML parser will require work. The easiest way to process RDF/XML is to use one of the many available RDF toolkits. These toolkits let you parse RDF documents into a triples data structure, modify the data, and write it back out again. Suppose as an implementer I want to use an RDF toolkit. Now I need to do extra work to implement the OSLC subset. If I implement a service, am I obligated to throw an exception if the incoming RDF does not conform to the OSLC subset? If I don't then I am lulling the client into a false sense of security since if they access a different service implementation, it may be less forgiving. Furthermore, when I try to generate RDF using the toolkit, it will not conform to the OSLC subset so I'll have to write my own serializer. We are therefore in the paradoxical situation of embracing RDF as our data model yet making life more difficult for implementers that want to use RDF toolkits. We started down the path of trying to make RDF look like "normal" XML in 2009. That was based on our perceived market adoption of RDF. I supported that decision based on some negative customer reaction to RDF versus plain old XML. However, during the past year there has been a dramatic increase in the amount of RDF on the Web as part of the Linked Open Data movement. There is a lot of adoption by the USA and UK governments. I think in 2010, RDF is a much less risky technology. The fact that we were led to using <rdf:RDF> as the root element, as well as using several other features of RDF/XML (e.g. blank node ids), should tell us that perhaps the features of RDF/XML are necessitated by the nature of the RDF data model itself, and that as we learn more, we'll be led to adopting more of RDF/XML syntax. We can simplify the Core spec if we simply adopt RDF/XML as a specified by W3C. This is in line with our use of other RDF formats, such as Turtle. One objection I heard was that RDF/XML would be hard to parse in a browser using Javascript. That same objection applies to the OSLC subset of RDF/XML. Our answer for the browser should be JSON, and by similar reasoning to the above, we should understand why we are not simply adopting one of the existing JSON encodings of RDF. e.g.from Talis. The potential advantage is the availability of toolkits for that encoding. Could you include this topic on the agenda of our next workgroup meeting? Thx. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Dave <[email protected]> To: oslc-core <[email protected]> Date: 06/30/2010 02:58 PM Subject: [oslc-core] Meeting notes and using rdf:RDF as root element Sent by: [email protected] I posted some notes on the Core meeting agenda page for today: http://open-services.net/bin/view/Main/OslcCoreMeetings20100630 One of the topics we discussed today was Link Guidance and the fact that the proposed form for "link annotated with property-values" requires <rdf:RDF> as the root element of OSLC Defined Resource representations. We discussed the impact of this change on implementations now in-flight and those moving from v1 to v2 and agreed that this change is late-breaking but not too late. If we wait a week, it may be too late so we agreed to get this change in now and then socialize and gather feedback. The change is now in the Core spec draft as well as the RDF/XML and Atom representation examples: http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixBDRAFT http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixEDRAFT Feedback is most welcome. Thanks, - Dave _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
