[oslc-core] Meeting notes and using rdf:RDF as root element
Dave
snoopdave at gmail.com
Thu Jul 8 11:59:15 EDT 2010
Hi Arthur,
You make a lot of good points and this certainly calls for further
discussion. Here's my initial take on the issue.
On Tue, Jul 6, 2010 at 7:19 PM, Arthur Ryman <ryman at ca.ibm.com> wrote:
> 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.
Having XML that looks like plain old XML is only one of the goals. I
think there are several more important goals in the data model &
representation rules approach we are taking in the OSLC Core spec:
- Make it easy for OSLC workgroups to define resources in terms of
properties allowed or required at creation, update and query times.
- Make it easy for OSLC provider and consumer implementations to
generate representations in consistent forms that are friendly to
those writing parsers
- Enable OSLC implementations to use standard XML, JSON, Turtle,
RDF/XML parsers and serializers to parse and generate OSLC resource
representations
If we just told people to "just use RDF/XML" or "use JSON" we would
end-up with lots of different ways to express the same thing and
clients & servers would have a hard time parsing he results with
standard XML and JSON parsing tools.
> 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.
I think Postel's Law applies here and I'll paraphrase it as: be
conservative in what you produce and liberal in what you consume
(http://en.wikipedia.org/wiki/Robustness_principle).
For OSLC service providers, this means two things. By providing the
RDF/XML representation "rules" we are encouraging service providers to
be conservative in what they produce, sticking to a simple subset of
RDF/XML that we need to express OSLC resources and this makes like
easier for consumers of the data -- who have to deal with less
variation.
While providers should be conservative in what they produce, they she
be liberal in what they consume. If valid RDF/XML is posted and
includes RDF/XML forms that are not part of the rules, that is not
cause for an exception to be thrown. At the same time, providers are
allow to discard unknown content.
For OSLC clients, this means two things as well. If clients want the
best chance of success, then they should be conservative and stick the
the RDF/XML subset expressed in the OSLC rules. And, clients should be
liberal in what they consume as well -- and in some sense that have to
be: clients are not allowed to discard unknown content.
> 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.
This could be a real issue and probably warrants some testing with
Jena and other RDF serializers. Can anybody comment in this issue?
> 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?
Yes.
Thanks,
Dave
> ___________________________________________________________________________
>
> 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
>
>
>
>
More information about the Oslc-Core
mailing list