Hi Nick
Thanks for response.
Vocab q#1: OK. So, should we simply delete the dcterms:description? Its content is a bit more verbose/explanatory than that in rdfs:comment, and includes examples.
Merging the content means that we diverge from the original 2.0 content.
Shape q#1: See attached figure for where in the shapes file I see it. I did also fix the vann:preferredNamespacePrefix, but that did not seem to help.
Shape q#2: Ok. I have now synchronised the shapes tables with those on
http://open-services.net/bin/view/Main/RmSpecificationV2
But this raised a new issue - Shape q#3:
In the original Shapes tables, a number of Properties have a different description when used in the Requirement table, compared to when used in the RequirementCollection
table.
Properties such as dcterms:contributor, affectedBy, constrainedBy, implementedBy, etc.
The latter differ because they exemplify the property using either Requirement or RequiremetCollection in the text.
But in the current document, it is not possible to have different descriptions, since it seems that we reuse the same property constraint definition in both
shapes. Right?
This is a minor issue, since luckily I did not find a problem in the other columns (such as occurs, range, etc).
But is there something fundamentally wrong in reusing the same property constraint in many shapes?
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
From: Nicholas Crossley [mailto:nick_crossley@us.ibm.com]
Sent: 17 January 2018 15:48
To: Jad El-Khoury
Cc: oslc-domains@lists.oasis-open.org
Subject: RE: [oslc-domains] Reconciling 2.0 domain specification base requirements with OSLC Core 3.0
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 <jad@kth.se>
To: "oslc-domains@lists.oasis-open.org" <oslc-domains@lists.oasis-open.org>
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: <oslc-domains@lists.oasis-open.org>
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
jad@kth.se,
www.kth.se
From:
oslc-domains@lists.oasis-open.org [mailto:oslc-domains@lists.oasis-open.org]
On Behalf Of Jim Amsden
Sent: 11 January 2018 20:32
To: oslc-domains@lists.oasis-open.org
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