Jad,
Vocab q#1: vocabulary terms must use
rdfs:comment, not dcterms:description for the explanatory text. This might
be wrong in the OSLC 2.0 source on open-services.net and not previously
noticed, because the tables in the OSLC 2.0 specifications are not generated
from the ttl files, but were written separately by hand.
Shape q#1: I don't see this - which
resources in which file? The namespace prefix should be "oslc_rm#",
and I see that in the appropriate places. That namespace prefix expands
to http://open-services.net/ns/rm#,
and I see that in appropriate places. I do see an error in /requirements-management-vocab.ttl
where vann:preferredNamespacePrefix "rm"
; should be vann:preferredNamespacePrefix
"oslc_rm" ; .
Shape q#2: The alphabetic sorting is
deliberate. The OSLC 2 tables were constructed manually, as I noted above,
so the author could sort however they wished. OSLC 3 tables are generated
automatically from the Turtle, where the RDF has no ordering, so without
sorting alphabetically, your properties would be shown in an unspecified
order determined by the implementation of the RDF libraries being used.
Nick.
From:
Jad El-Khoury <>
To:
""
<>
Date:
01/16/2018 03:22 PM
Subject:
RE: [oslc-domains]
Reconciling 2.0 domain specification base requirements with OSLC Core 3.0
Sent by:
<>
Hi
I now went through the RM
2.0 specification again, comparing the text to the original 2.0 on open-services.net.
Here’s a summary of the changes I have made.
Does it make sense to share
a screen during our telco, and going through these changes live?
Jim! I have two questions
first:
Vocabulary
I compared to the content
on http://open-services.net/bin/view/Main/RmVocabulary
The dcterms:description is
not shown in html, but it exists correctly in the ttl file!
Q: How do we make
the dcterms:description text visible? It is visible on open-services.net
Shapes
Q: Why is the resource
name preceded with "rm#"?
Q: Shape properties
are ordered alphabetically, which makes less sense, compared to the
more intuitive listing on open-services. Can we control that?
SUMMARY of CHANGES
1. Introduction
I changed the 1st paragraph,where I refer to
oslc3.0 instead of 2.0.
1.2 Terminology
I renamed “Service Provider” as “Server”,
and changed its definition
I renamed “Service Consumer” as “Client”,
and changed its definition
à
Throughout the paper, I also change Provider/consumer, with Server/Client.
2. Base Requirements
I state “This specification is based on [OSLCCore3]”,
insteasd of the original reference to “OSLC 2.0”
I replaced "Service Provider Resources"
with "Discovery". Also, I added to the original text ("OSLC
servers MAY provide a Service Provider Catalog, MUST provide a Service
Provider resource"), the following: ", and MAY provide other
forms of discovery described in Core 3.0 Discovery."
2.2 Specification Versioning
I removed all additional text, and simply refer
to core3.0
2.8 Requesting and Updating
Properties
I copied from CM specs.
2.9 Labels for Relationships
I copied from CM specs.
I still have the job of checking
the Shapes tables (there are differences to fix). I plan to do that before
our Thursday meeting.
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
,
www.kth.se
From:
[mailto:]
On Behalf Of Jim Amsden
Sent: 11 January 2018 20:32
To:
Subject: [oslc-domains] Reconciling 2.0 domain specification base requirements
with OSLC Core 3.0
I went through the AM 2.0 specification comparing
the base requirements with CM 3.0. I found the following potential incompatibilities
with Core 3.0:
1. RDF serialization format - AM specifies MUST for RDF/XML which is OK,
but doesn’t mention turtle or json-ld. - Recommendation: change to follow
Core 3.0 RDF serialization formats, including proposal to change core RDF
serialization formats clauses.
2. Discovery - AM says ServiceProvider resource is MUST, Core MAY - Recommendation:
ok to strengthen compliance level in a domain spec, so no problem. However
this should just say MUST support OSLC discovery, and need not say exactly
how. Servers just follow core which already covers OSLC 2.0 discovery compatibility.
So not much there. Other domain specs should retain the base capabilities
and supporting text from the OSLC 2.0 specifications unless there's some
compelling reason they can't. In particular, the RM spec should not have
copied the CM base requirements, but instead stick with the ones in the
RM 2.0 spec.
Here's the details:
Architecture Management
Thu Jan 11 09:39:53 EST 2018
Analyzing the differences between CM
3.0 and
AM
2.0 Base
Requirements.
The result of this analysis applies to the subsections of the document
as well. Ideally these would be cloned and be quite similar for each domain
specification.
CM
3.0 Requirement
Level
Meaning
AM
2.0 Differences
Unknown
properties and content
may/
must
OSLC
servers mayignore
unknown content and OSLC clients mustpreserve
unknown content
Client
MUST is in a separate entry.
Resource
Operations
must
OSLC
service mustsupport
resource operations via standard HTTP operations
Resource
Paging
may
OSLC
servers mayprovide
paging for resources but only when specifically requested by client
Paging
is SHOULD for query results, MAY on large resource entity response bodies.
Partial
Resource Representations
must
OSLC
servers mustsupport
request for a subset of a resource’s properties via the oslc.properties
URL parameter retrieval via HTTP GET
AM
is MAY support selective properties
Partial
Update
may
OSLC
servers maysupport
partial update of resources using [LDPPatch], or via HTTP PUT.
Discovery
may/
should
OSLC
servers shouldprovide
a ServiceProvider resource for Core v2 compatibility, mayprovide
a ServiceProviderCatalog, and mayprovide
other forms of discovery described in Core 3.0 Discovery.
Specifically
states MUST provide ServiceProvider resource. Servers MAY support ServiceProviderCatalog
Creation
Factories
must
OSLC
servers mustprovide
LDPC creation factories to enable resource creation of Change Management
resources via HTTP POST
Creation
factory capability is MAY, and also servers MAY support creation factories
in other resource serialization formats indicated with oslc:usage.
Query
Capabilities
should
OSLC
servers shouldprovide
query capabilities to enable clients to query for resources
query
capability is a MUST
Query
Syntax
should/
may
OSLC
query capabilities shouldsupport
the OSLC Core Query Syntax and mayuse
other query syntax
Delegated
UI Dialogs
must/
should
OSLC
Services mustoffer
delegated UI dialogs (creation and selections) specified via OSLC Core
3.0 Delegated Dialogs and shouldinclude
discovery through a ServiceProvider resource for OSLC v2 compatibility
Delegated
selection UI is SHOULD, delegated creation dialog is separate entry and
MAY.
UI
Preview
should
OSLC
Services shouldoffer
UI previews for resources that may be referenced by other resources specified
via OSLC Core 3.0 Preview and shouldinclude
discovery through a server resource for OSLC v2 compatibility
Authentication
may
OSLC
Services shouldfollow
the recommendations for Authentication specified in [OSLCCore3]
SHOULD
support one of the OSLC Core recommendations, Has separate MAY for each
one (HTTP Basic, OAuth, Form)
Error
Responses
should
OSLC
Services shouldprovide
error responses using OSLC Core 3.0 defined error formats
Turtle
Representations
must
OSLC
servers mustprovide
a Turtle representation for HTTP GET requests and shouldsupport
Turtle representations on POST and PUT requests.
RDF/XML
Representations
should
OSLC
servers shouldprovide
an RDF/XML representation for HTTP GET requests and shouldsupport
RDF/XML representations on POST and PUT requests for compatibility with
Change Management 2.0.
RDF/XML
is MUST
XML
Representations
should
OSLC
servers shouldprovide
a XML representation for HTTP GET, POST and PUT requests that conform to
the Core 2.0 Guidelines for XML.
JSON
Representations
must
OSLC
servers mustprovide
JSON-LD representations for HTTP GET, POST and PUT requests that conform
to the Core Guidelines for JSON-LD
HTML
Representations
should
OSLC
servers shouldprovide
HTML representations for HTTP GET requests
Other Differences:
Servers
MUST use absolute URIs - not sure this is a good idea, but its there, so
ok to keep it.
Servers
MUST support If-Match header on PUT and DELETE - note mentioned in CM,
but may be in Core 3.0
Unique
AM Link Type Query Capability
CM does
not specify which HTTP resource operations may, must, or should be provided
- AM say PUT & DELETE are SHOULD, may be covered in Core.
Specifically
states servers SHOULD support paging for queries
Potential conflicts with OSLC Core 3.0:
RDF serialization
format - AM specifies MUST for RDF/XML which is OK, but doesn’t mention
turtle or json-ld. - Recommendation: change to follow Core 3.0 RDF serialization
formats
Discovery
- AM says ServiceProvider resource is MUST, Core MAY - Recommendation:
ok to strengthen compliance level, so no problem, should just say MUST
support OSLC discovery, and need not say exactly how. Servers just follow
core.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
