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
