After some good feedback from Martin, I made changes to the new spec text: http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT#Guidelines_for_RDF_XML
We'll discuss this and a finalization proposal tomorrow in the Core WG meeting. Thanks, - Dave On Mon, Jul 12, 2010 at 3:01 PM, Dave <[email protected]> wrote: > I captured it as issue #19 in the RDF/XML section: > http://open-services.net/bin/view/Main/OslcCoreV1Issues > > I added added OSLC Core spec text that specifies the scheme you proposed: > > For those catching up: the basic idea is this: OSLC specs can allow > either abbreviated RDF/XML, full RTDF/XML or both forms and use > content-negotiation to determine what is returned. This will allow > specs to require abbreviated RDF/XML now and later add full RDF/XML > without breaking clients. The new spec text describes these three > options, how content negotiation works and how to do abbreviated > RDF/XML with Jena. > > This shouldn't change anything for provider implementations, but > XML-only consumers will need to know to ask for application/xml or > risk breakage later. > > As always feedback is most welcome. > > Thanks, > - Dave > > > > On Fri, Jul 9, 2010 at 1:36 PM, Arthur Ryman <[email protected]> wrote: >> Dave, >> >> Seems like we are making good progress. Here are the points we need to >> settle. >> >> 1. Be more formal about the OSLC subset so that RDF folks can easily >> generate it e.g. using RDF/XML-ABBREV rules, and so XML processors can >> create more robust code. >> 2. Use HTTP content negotiation to differentiate between full W3C RDF/XML >> and the OSLC subset. >> >> 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 <[email protected]> >> To: >> [email protected] >> Date: >> 07/09/2010 11:18 AM >> Subject: >> Re: [oslc-core] Meeting notes and using rdf:RDF as root element >> Sent by: >> [email protected] >> >> >> >> 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 >>> >> >> _______________________________________________ >> Oslc-Core mailing list >> [email protected] >> http://open-services.net/mailman/listinfo/oslc-core_open-services.net >> >> >> >> >
