oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: FW: [oslc-domains] OSLC RM Domain specs
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
- Date: Thu, 7 Dec 2017 12:49:08 -0500
Jad,
We may have gotten this wrong, same
as with OSLC Core 2.0 and LDP paging. First, the actual RDF serialization
format is not something that OSLC should even need to address. OSLC should
only specify that the resources are represented as any standard RDF format.
The reason is that no OSLC client should ever depend on a specific resource
serialization representation, and they should utilize RDF parsers that
support any standard representation. Otherwise interoperability suffers.
Now unfortunately this is not the case.
Some tools rely on RDF/XML with inlined resources, even going so far as
to expect the results to be in RDF/XML-ABBREV, something that isn't even
a standard. These clients may use XPath or other lexical mechanisms to
"parse" these RDF/XML files for their convenience, and to avoid
using RDF parsers. So we have to deal with this.
For OSLC, interoperability with 2.0
clients and servers is more important than whether RDF/XML, Turtle or JSON-LD
is the serialization format. Since we know there are implementations that
are limited to RDF/XML, then we should continue to support that in OSLC
3.0 and the domain specifications.
I would prefer to change all these to
SHOULD, and to document in the clause why - SHOULD support Turtle and JSON-LD
because they are simpler, more readable representations mandated by LDP.
SHOULD support RDF/XML because it is required by OSLC 2.0 and there are
many existing clients and servers you might want to integrate with.
Now what the servers provide is not
over specified and left to what they need to provide in their broader execution
environment.
See https://issues.oasis-open.org/browse/OSLCCORE-142
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
Jad El-Khoury <jad@kth.se>
To:
Jim Amsden <jamsden@us.ibm.com>,
Andrii Berezovskyi <andriib@kth.se>
Date:
12/07/2017 11:02 AM
Subject:
FW: [oslc-domains]
OSLC RM Domain specs
The
argument to requiring Turtle in Core 3.0
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering
and Management, Mechatronics Division
Brinellvägen 83, SE-100 44
Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile:
+46(0)70 773 93 45
jad@kth.se,
www.kth.se
From: Nicholas Crossley [mailto:nick_crossley@us.ibm.com]
Sent: 15 November 2017 20:25
To: Jad El-Khoury
Cc: Jim Amsden; Schulte, Mark D; oslc-domains@lists.oasis-open.org
Subject: Re: [oslc-domains] OSLC RM Domain specs
We discussed this before in the context of
Core 3.0, or parts thereof.
The thinking was this:- We do want new implementations to
support Turtle, so we want to make that a MUST.
- We would like to move away from RDF/XML
because it's really difficult to read, and because we don't want to burden
new implementations with unnecessary representations, so we make that optional.
- Servers that feel compatibility with
OSLC 2.0 is important are welcome to provide RDF/XML - the standard allows
it.
So technically yes, it's an incompatible change - but that incompatibility
is the choice of the server, so we felt it was OK.
For version numbering, we can't call it 2.0, because there are some differences.
I thought we had agreed on 2.1 or 2.0.1 or something?
Nick.
From: Jad El-Khoury
<jad@kth.se>
To: Jim Amsden
<jamsden@us.ibm.com>,
"Schulte, Mark D" <mark.d.schulte@boeing.com>,
"oslc-domains@lists.oasis-open.org"
<oslc-domains@lists.oasis-open.org>
Date: 11/15/2017
03:36 AM
Subject: [oslc-domains]
OSLC RM Domain specs
Sent by: <oslc-domains@lists.oasis-open.org>
Hi,
I raised the issue of RM 2.0 compatibility with OSLCCore3.0, and here’s
an example (I think I earlier found another example, but let’s first test
if I understood compatibility correct):
OSLC Core 3.0, states that OSLC Services MUST provide and accept text/turtle
http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part1-overview/oslc-core-v3.0-cs01-part1-overview.html#resourceRepresentations
RM 2.0 only requires MUST for RDF/XML representations.
Now, if we state that RM 2.0 specification is based on OSLCCore3.0, does
that not create a backward compatibility issues for RM2.0? Existing RM
2.0 implementations have not necessarily supported turtle.
Also, note that I have also just committed some new changes to the RM Specs.
I earlier called the specs 3.0, but now I understand we should stick to
2.0. So, I now renamed it 2.0.
This also meant I have reverted changes to the following sections to be
almost the same text as that under open-services:
* 2.2 Specification Versioning
* Appendix A. Version Compatibility with 2.0 Specifications
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@kth.se,
www.kth.se
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]