[oslc-core] Meeting notes and using rdf:RDF as root element

[Steve K Speicher]

> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Dave <snoopdave at gmail.com>
> Cc: oslc-core <oslc-core at open-services.net>, oslc-core-bounces at open-
> services.net
> Date: 07/06/2010 07:20 PM
> Subject: Re: [oslc-core] Meeting notes and using rdf:RDF as root element
> Sent by: oslc-core-bounces at open-services.net
> 
> 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.
> 

I wonder if simply requiring us to have a root element of <rdf:RDF> causes 
us to cross that line between just enough RDF/XML to too much.
Your point about the usage of content type of application/rdf+xml is valid 
to me, though this mostly becomes a potential issue on POST/PUT with these 
formats.
I would believe most OSLC service providers would not generate varying 
RDF/XML formats when requested.
One possible approach is to address how one can identify this RDF/XML 
subset defined by OSLC.  Though, we could argue that we are putting the 
same constraints on application/json in that we are defining how we are 
representing "OSLC JSON" and not working with arbitrary JSON.

Looking to the Web for similar patterns, HTML 4 and 5, as well as XHTML 
Mobile Profile.  In fact the guidance for MIME type for XHTML-MP has *The 
MIME type for XHTML Mobile Profile is "application/vnd.wap.xhtml+xml". 
Conforming user agents should also accept "application/xhtml+xml" and 
"text/html" *.   The registered text/html MIME type as an example, has/had 
a number of parameters like 'charset' but some like 'version' and 'level' 
have been dropped from the spec due to lack of usage.  Just thinking if 
one wanted to go down the route of saying - Content-type: 
application/rdf+xml;profile=oslc which doesn't appear much precedence for 
this and I could imagine it breaking some existing implementations.

So I believe we can define a subset, we just need to be clear on how we 
handle discrepancies, which HTTP already has a number of status codes for 
this.

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

Perhaps it would be valuable for us to quantify the "already using most of 
the RDF/XML syntax" to better understand what we are missing.
 
> 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.
> 

My #1 concern with taking on full RDF/XML at this point is that it would 
have major impact on implementations that are occurring now.  Forcing them 
to change directions to adopt usage of RDF/XML parsers: not just code 
changes, testing and other needs, this could not be done in time to meet 
current committed plans.

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

I think we should possibly target 2011 versions of specifications and 
implementations to be fully RDF/XML compliant and have a roadmap on how we 
get there with current Core's subset of RDF/XML.

> 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 <snoopdave at gmail.com>
> To:
> oslc-core <oslc-core at open-services.net>
> Date:
> 06/30/2010 02:58 PM
> Subject:
> [oslc-core] Meeting notes and using rdf:RDF as root element
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 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
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net