[oslc-core] Meeting notes and using rdf:RDF as root element
Dave
snoopdave at gmail.com
Tue Jul 13 17:21:34 EDT 2010
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 <snoopdave at gmail.com> 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 <ryman at ca.ibm.com> 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 <snoopdave at gmail.com>
>> To:
>> oslc-core at open-services.net
>> Date:
>> 07/09/2010 11:18 AM
>> Subject:
>> Re: [oslc-core] Meeting notes and using rdf:RDF as root element
>> Sent by:
>> oslc-core-bounces at open-services.net
>>
>>
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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