OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (OSLCCORE-142) OSLC Core 3.0 should not mandate any particular RDF serialization format


    [ https://issues.oasis-open.org/browse/OSLCCORE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68464#comment-68464 ] 

Andrii Berezovskyi commented on OSLCCORE-142:
---------------------------------------------

I understand your concern regarding the compatibility but I am concerned with making sure OSLC 3 does not fade into irrelevance in the "microservice era".

If I were a Node developer and would see that RDF/XML is a MUST, I would do a quick search on npm, see that the best libraries do not support XML (i.e. those I can use both in Node and on the browser side and which have good performance and are maintained) and close the OSLC site without reading further.

As a Swift developer, I would look for an RDF library, see that it supports Turtle, TRiG, NTriples, and NQuads. Then I would close the OSLC website w/o reading further. I think you get the idea.

As for Turtle, I agree that the server should support it but I am afraid that SHOULD will make everyone take it a guidance to request and implement Turtle only instead of a proper Accept header. Again, as Jim said, all of these are just serialisation formats.

Also, some enterprises we talked to are considering to mandate a single RDF format like Turtle or RDF/XML everywhere inside their organisation. Thet have a vague understanding of content neg, which I think OSLC specs should highlight. That would actually increase the implementation burden a bit but will ensure truly interoperable and future-proof solutions, at least on the format level. And preclude mishaps like one with rdf/xml-abbrev or the reliance on the triple order in the OSLC Query results from happening in the future because a requirement to respect negotiation will forbid server/client developers from thinking in terms of the format specifics.

So when I see a Node REST server in the next few years serving OSLC resources in JSON-LD for the browser clients, Turtle for that Swift client on iOS or Mac and replying 406 Not Acceptable to application/rdf+xml, I want to say it's OSLC 3 compliant but that it SHOULD add XML support to be backwards compatible with 2.0.

> OSLC Core 3.0 should not mandate any particular RDF serialization format
> ------------------------------------------------------------------------
>
>                 Key: OSLCCORE-142
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-142
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>          Components: Core
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> 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. 
> OSLC Core 3.0, and the OSLC domain specifications change all references to specific RDF serialization formats to SHOULD, and document in the clause why. Clients and servers SHOULD support Turtle and JSON-LD because they are simpler, more readable representations mandated by LDP. Clients and Servers 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 is left to what they need to provide in their broader execution environment.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]