[oslc-core] Meeting notes and using rdf:RDF as root element
Dave
snoopdave at gmail.com
Fri Jul 9 11:18:01 EDT 2010
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 <ryman at ca.ibm.com> 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 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
>
>
>
>
> _______________________________________________
> 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