[oslc-core] Fw: Meeting notes and using rdf:RDF as root element
Martin Nally
nally at us.ibm.com
Fri Jul 9 12:10:35 EDT 2010
>> If OSLC swallows RDF whole, we end up in a
position where everyone consuming and providing OSLC domain specs will
only be able to do so using full-fledged RDF/XML parsers. No consumer
would ever be able to parse a resource with a regular XML parser, or use
simple XML tools like xpath to extract a couple of values of interest.
Overall you make good points, Jim, but this comment is based on a
misunderstanding of what is being proposed. No-one that I have talked to is
proposing anything that would require that all OSLC consumers have to
process arbitrary RDF. Let me explain.
Here are some statements that I take as given:
We needed an RDF representation of OSLC resources for some use-cases
that are fundamental to IBM. These use-cases are typically found in
"generic" applications of which examples are query and reporting. Likely
not everyone understands or agrees that we need this, but this is a
non-negotiable requirement for IBM. For these scenarios, we do not care
if the RDF representation is RDF/XML, Turtle, NTuples or N3. Turtle is
my preferred format by far, but any of them will do. The applications
that implement these scenarios certainly do not care about one style of
RDF/XML versus another. We have a good understanding today of the read
scenarios for which we need for RDF. I believe there will also be
important creation and update scenarios that require RDF in the future,
but these are less well understood. RDF update will probably also
require PATCH (partial update) rather than PUT. Creation and update
through RDF is a topic we can defer for this year.
Many people think they need an XML representation for particular
resources in particular domains. My personal view is that XML is almost
never the best choice, even for domain-specific scenarios, but XML has
broad mind-share and good technology support, so having an XML
representation for a domain is fine. Domain-specific scenarios usually
need creation and update as well as read immediately.
JSON and possibly also other representations are also important, both
for read and write.
We should never make up domain-specific media types - we should use
standards ones like text, json, application+xml, application+xml/rdf,
turtle, ....
We know that often, but not always, you can design a single representation
that satisfies both XML and RDF needs - it's valid RDF/XML and it's
"reasonable" XML. This is the "happy pattern" for people who want XML and
must satisfy the need for RDF. At some point someone decided we should
actually mandate this pattern, rather than just point out that it exists,
and is useful. In my opinion this is a mistake - there never was any good
reason to mandate this - we simply got confused between a good practice
applicable in a subset of cases, and a true requirement.
We are finding more and more cases where the "happy pattern" representation
is not adequate. Query results are one of the cases that does not fit the
happy pattern. So are paginated results (which are a kind of query). This
should not be a problem - you should be able to use the happy pattern where
it works and you don't use it where it doesn't. However, we have got
ourselves in a bind by trying to mandate the "happy pattern" rather than
just saying it's a useful/recommended pattern where it works. Worse, we are
now trying to extend the definition of the happy pattern to accommodate the
new cases, so the "happy pattern" is beginning to look less and less happy
- it is well down the slope to becoming simply a restatement of RDF/XML.
We should not try to extend the definition of the "happy pattern" to
accommodate more complex scenarios like query and pagination that do not
easily fit the happiest form of the happy pattern. Those scenarios require
a significantly broader subset of RDF/XML if you want a single
representation of them for both XML and RDF, and extending the happy
pattern definition to accommodate these sort of cases will turn into a
pointless restatement of RDF/XML, and also destroy the original value of
the happy pattern. This is the core point that Arthur is making that is
being misunderstood.
The proposed resolution does not require people to parse full RDF. The
rules are very simple:
You must expose an RDF representation. You don't have to consume it
(because we don't require RDF create and update, at least not this
year), but you do have to produce it. It doesn't have to be RDF/XML, but
it can be, and if you choose RDF/XML, we don't care what style you use.
It can't be second-rate - it has to be a full representation of the
resource.
You can expose other representations if you like - XML, JSON. You will
have to consume as well as produce these, and your clients will have to
like them, so you will want to pay attention to the consumability of the
representations.
You can't make up your own media types
If you can satisfy 1), 2) and 3) for your domain with one representation
with the happy pattern and you are content with the results, then more
power to you. If you can't or don't like the result, that is fine too.
There is similarly little benefit that I can see to mandating a particular
style of JSON.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Scott Bosworth/Raleigh/IBM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Martin Nally/Raleigh/IBM at IBMUS |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|07/09/2010 08:11 AM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Fw: [oslc-core] Meeting notes and using rdf:RDF as root element |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
fyi - interesting debate...Scott
Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 919.486.2197
(w) | 919.244.3387(m) | 919.254.5271(f)
----- Forwarded by Scott Bosworth/Raleigh/IBM on 07/09/2010 08:10 AM -----
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-core at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|07/08/2010 05:32 PM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [oslc-core] Meeting notes and using rdf:RDF as root element |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Arthur,
> The OSLC subset and generation rules result in RDF/XML documents that
are a subset of all possible valid RDF/XML documents.
> If we supported full RDF/XML I wouldn't need to spend time on the
syntactic details.
This is quite deliberate. If OSLC swallows RDF whole, we end up in a
position where everyone consuming and providing OSLC domain specs will
only be able to do so using full-fledged RDF/XML parsers. No consumer
would ever be able to parse a resource with a regular XML parser, or use
simple XML tools like xpath to extract a couple of values of interest.
This is explained in
http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT#OSLC_Defined_Resource_Representa
Here's the relevant passage:
RDF/XML defines an extensive set of XML elements and attributes for
representing an RDF data model. RDF/XML provides a lot of flexibility and
if we allowed each OSLC workgroup to decide now to serialize OSLC
resources to and from RDF/XML, we would require each workgroup to master
RDF-XML, we would end-up with different serializations for each domain,
the XML produced would not be XML-tool friendly and in the end
interoperability would suffer.
To ensure that the RDF/XML produced by OSLC services is uniform, easy to
understand and as simple as possible, we define a set of step-by-step
rules for generating the RDF/XML. We use a very limited set of RDF
elements and attributes, the rdf:type element and attributes rdf:about,
rdf:resource= and =rdf:nodeID.
I, for one, think this was the right direction for OSLC Core to go.
Regards,
Jim des Rivieres
Rational AMC Technical Lead
----- Forwarded by Jim des Rivieres/Ottawa/IBM on 07/08/2010 04:17 PM
-----
From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Steve K Speicher <sspeiche at us.ibm.com>
Cc:
oslc-core <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date:
07/08/2010 03:46 PM
Subject:
Re: [oslc-core] Meeting notes and using rdf:RDF as root element
Sent by:
oslc-core-bounces at open-services.net
Steve,
I am not referring to the use of <rdf:RDF> element since that is a part of
RDF/XML. I am referring to the exclusion of those features of RDF/XML that
are not part of the OSLC subset. The OSLC subset and generation rules
result in RDF/XML documents that are a subset of all possible valid
RDF/XML documents. There is no guarantee that when I serialize an RDF
graph using some toolkit that the result will fall within the subset
defined by OSLC.
For example, the document might contain multiple <rdf:Description>
elements for the subject nodes instead of "inlining" the triples under
some main subject node, or a subject node might not use the expected
rdf:type abbreviation if it had multiple types. There are other features,
such as rdf:parseType="Resource" and rdf:parseType="Collection" that are
not in the OSLC subset, but that might get generated. Those are simply
abbreviations that produce more compact and readable documents, but that
are not in the OSLC subset. A serializer could generate them.
On a related thought, consider the issue of "enforcing" conformance to the
OSLC subset.
Currently, the OSLC subset is described implicitly, i.e. as the result of
applying the representation rules. This means there is no programmatic way
to check conformance of an RDF/XML document with the OSLC rules. However,
I don't think it would be a good use of our time to create an OSLC
validator. We don't want to enshrine this subset since it's very likely to
change (and probably coincide with RDF/XML eventually).
Here's a real-world example. Today I reviewed a design for calendar
events, based on the RDF representation of the iCal standard. Here's a
sample RDF/XML representation:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:jc="http://jazz.net/xmlns/prod/jazz/calendar#" xmlns="
http://www.w3.org/2002/12/cal/icaltzd#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<VCalendar>
<jc:calendar_owner rdf:parseType="Resource">
<foaf:mbox rdf:resource="mailto:user at local.net>" />
<foaf:nick>user</foaf:nick>
</jc:calendar_owner>
<component>
<Vevent>
<jc:ownerResource rdf:parseType="Resource"
>
<foaf:nick>user</foaf:nick>
</jc:ownerResource>
<dtstart rdf:datatype="
http://www.w3.org/2002/12/cal/icaltzd#dateTime">2010-01-01T09:00:00Z</
dtstart>
<dtend rdf:datatype="
http://www.w3.org/2002/12/cal/icaltzd#dateTime">2010-03-31T18:00:00Z</
dtend>
<transp>TRANSPARENT</transp>
<rrule rdf:parseType="Resource">
<freq>WEEKLY</freq>
<byday>MO,TU,WE,TH,FR</byday>
</rrule>
</Vevent>
</component>
</VCalendar>
</rdf:RDF>
This is valid RDF/XML. It uses standards like iCal and FOAF. However, it
is invalid wrt to OSLC subset. Note the use of rdf:parseType="Resource".
Also note the use of the iCal dateTime datatype, which is not on the
approved list of datatypes. I don't think it's a good use of anyone's
time to try to hammer this into a shape that matches the OSCL subset. I'd
rather just focus on the data and interface. If we supported full RDF/XML
I wouldn't need to spend time on the syntactic details.
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:
Steve K Speicher <sspeiche at us.ibm.com>
To:
Dave <snoopdave at gmail.com>
Cc:
oslc-core <oslc-core at open-services.net>
Date:
07/08/2010 02:39 PM
Subject:
Re: [oslc-core] Meeting notes and using rdf:RDF as root element
Sent by:
oslc-core-bounces at open-services.net
> > 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?
>
I inquired on this to a team that I know has been using RDF/XML (Jena) for
some time, they said they didn't have this issue. In fact, they had to do
some unnatural acts to remove <rdf:RDF> root element, so adding that back
has made things much simpler.
- Steve
_______________________________________________
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
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100709/1f9df688/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100709/1f9df688/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100709/1f9df688/attachment-0001.gif>
More information about the Oslc-Core
mailing list