Arthur, this is starting to sound pretty good and it addresses my main concern with the RDF/XML subset approach, which is: what do we do if sometime in the future we decide to allow full RDF/XML?
With your approach, clients that want the subset ask for it with application/xml and that will always work no matter what we decide to return for application/rdf+xml - Dave On Fri, Jul 9, 2010 at 9:15 AM, Arthur Ryman <[email protected]> wrote: > > 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@IBMCA > To: > [email protected] > Date: > 07/08/2010 05:34 PM > Subject: > Re: [oslc-core] Meeting notes and using rdf:RDF as root element > Sent by: > [email protected] > > > > 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@IBMCA > To: > Steve K Speicher <[email protected]> > Cc: > oslc-core <[email protected]>, > [email protected] > Date: > 07/08/2010 03:46 PM > Subject: > Re: [oslc-core] Meeting notes and using rdf:RDF as root element > Sent by: > [email protected] > > > > 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:[email protected]"; /> > <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 <[email protected]> > To: > Dave <[email protected]> > Cc: > oslc-core <[email protected]> > Date: > 07/08/2010 02:39 PM > Subject: > Re: [oslc-core] Meeting notes and using rdf:RDF as root element > Sent by: > [email protected] > > > >> > 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net >
