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

Arthur Ryman ryman at ca.ibm.com
Fri Jul 9 09:15:46 EDT 2010


Jim,

I agree that we should make life easy for people who like XML and are 
comfortable with it, just as we should make life easy for people who like 
JSON and are comfortable with it. By the same token, we should make life 
easy for people who like RDF and are comfortable with it. However, the 
current approach fails to make life easy for XML folks, and at the same 
time makes life hard for RDF folks. By altering the meaning of 
application/rdf+xml, we make life hard for both the XML and RDF 
communities. 

I say we are not really making life easy for XML people because in the XML 
community, people are used to getting some machine-processible description 
of the format which allows them to validate the document and possibly even 
generate a parser. The common description formats are XSD, DTD, Relax NG, 
Schematron, etc. In our case, we provide no such description. We only give 
a verbal description of how to generate "valid" representations. What can 
an XML developer actually rely on in the OSLC subset? How can an XML 
developer design XSLT or XPath so that it won't break? In the absence of a 
more formal description of the OSLC subset, I think this type of 
processing would be fragile.

Similarly, we are not making life easy for RDF people because now they 
have to generate RDF/XML that conforms to the OSLC subset, or else risk 
breaking consumers. There are many equivalent ways to represent the same 
set of triples. OSLC RDF/XML makes some of those ways invalid. Given an 
RDF graph as input, there is no guarantee that a toolkit will generate an 
RDF/XML representation of it that falls within the OSLC subset.

I suggest that the "correct" way to serve each community is to:
1. not alter the meaning of application/rdf+xml, and 
2. allow domains to define "real" XML formats and use application/xml for 
them. We could regard the OSLC RDF/XML subset as a "default" 
application/xml representation. 

We can handle this situation satisfactorily through standard HTTP content 
negotiation. Let's confine the discussion to the XML-based 
representations. Here are the principles:

1. Use application/rdf+xml for content that conforms to the W3C RDF/XML 
standard, without any restrictions
2. Use application/xml for content that is well-formed W3C XML. A special 
case of this is an XML document that starts with <rdf:RDF> and conforms to 
the OSLC RDF/XML subset.
3. If a consumer (client or service) cannot process W3C RDF/XML, then it 
MUST NOT use application/rdf+xml in its HTTP Accept header.
4. If a provider (client or service) cannot generate OSLC RDF/XML, then it 
MUST NOT return application/xml content.

Here are the cases:
1. The client can process incoming W3C RDF/XML. This is the maximally 
interoperable case since OSLC RDF/XML is a subset of W3C RDF/XML. The 
client sends

        Accept: application/rdf+xml

The server can return either OSLC RDF/XML or W3C RDF/XML and gives it 

        Content-type: application/rdf+xml.

2. The client can only process incoming OSLC RDF/XML. The client sends 

        Accept: application/xml

If the server can generate OSLC RDF/XML then it returns it

        Content-type: application/xml 

Otherwise the server responds with 

        406 Not Acceptable.

--------

Instead of using application/xml as sugested above, another way to handle 
this is to use the quality indicator on the Accept header. The quality 
indicator (from 0 to 1) says how well the client can process the media 
type. Since OSLC RDF/XML is valid W3C RDF/XML, we could assign a quality 
level to it, e.g. 0.5.  The way to indicate that you can process only the 
OSLC subset of RDF/XML would be:

        Accept: application/rdf+xml; q=0.5

The OSLC subset would then use

        Content-type: application/rdf+xml

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:
Jim des Rivieres/Ottawa/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
07/08/2010 05:34 PM
Subject:
Re: [oslc-core] Meeting notes and using rdf:RDF as root element
Sent by:
oslc-core-bounces at open-services.net



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







More information about the Oslc-Core mailing list