[oslc-plm] [oslc-core] Meeting notes and using rdf:RDF as root element
michael.loeffler at gm.com
michael.loeffler at gm.com
Mon Jul 12 15:49:05 EDT 2010
I've been catching up on this thread after being out last week, it seems
the solution proposed makes a lot of sense. I did some digging into other
uses of RDF/XML in the PLM space to see if there were issues that might
drive the discussion one way or the other on this. There has been quite a
bit of interesting work done on this topic that might be valuable for us
to build on in the ALM-PLM workgroup, some details can be found at this
sampling of sites (there are quite a few others):
http://docs.oasis-open.org/plcs/dexlib/R1/dexlib/oasis_cover.htm
http://www.tc184-sc4.org/SC4_Open/Meetings/Previous_Meetings/Parksville-2009/Files/OTF%20Gellish-RDF%20named%20graph%20LRu%20V3.pdf
http://www.nist.gov/customcf/get_pdf.cfm?pub_id=903057
http://www.nist.gov/customcf/get_pdf.cfm?pub_id=901544
I'll try to form a more coherent view on this and share it in a future
meeting.
Thanks.
---
Mike Loeffler - Global Electrical IT Architecture
GM Electrical, Controls & Software
From:
Dave <snoopdave at gmail.com>
To:
oslc-core at open-services.net
Date:
07/12/2010 03:02 PM
Subject:
Re: [oslc-core] Meeting notes and using rdf:RDF as root element
Sent by:
oslc-core-bounces at open-services.net
I resolved this issue.
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:
http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT#Three_options_for_RDF_XML
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
>
>
>
>
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-plm_open-services.net/attachments/20100712/8a0b81c3/attachment-0003.html>
More information about the Oslc-Plm
mailing list