Vocab q#1: I would suggest a judicious
merge of the previous rdfs:comment and dcterms:description. It is OK to
diverge from the 2.0 content if what we change or add clarifies the existing
meaning.
Shape q#1: This was a defect in ReSpec
- which I have now fixed.
Shape q#3: I had the same issue in Configuration
Management. I ended up using the exact same property definition for two
or more instances of the same property in different shapes if and only
if I wanted exactly the same fields for all. If I wanted different fields,
I created near-copies of the property definition for two or more property
instances in each of the relevant shapes. For example, in configuration
management shapes I have two near-identical property definitions for dcterms:contributor:
<#bcontributor>
a
oslc:Property ;
oslc:name
"contributor" ;
oslc:propertyDefinition dcterms:contributor
;
oslc:occurs
oslc:Zero-or-many ;
oslc:readOnly
true ;
oslc:representation
oslc:Either ;
oslc:valueType
oslc:AnyResource ;
oslc:range
foaf:Person, foaf:Agent ;
dcterms:description
"""Contributor or contributors to the resource.
The link target is usually a <code>foaf:Person</code>
or <code>foaf:Agent</code>, but could be any type."""^^rdf:XMLLiteral
.
<#contributor>
a
oslc:Property ;
oslc:name
"contributor" ;
oslc:propertyDefinition dcterms:contributor
;
oslc:occurs
oslc:Zero-or-many ;
oslc:representation
oslc:Either ;
oslc:valueType
oslc:AnyResource ;
oslc:range
foaf:Person, foaf:Agent ;
dcterms:description
"""Contributor or contributors to the resource.
The link target is usually a <code>foaf:Person</code>
or <code>foaf:Agent</code>, but could be any type."""^^rdf:XMLLiteral
.
The only difference is in the oslc:readOnly
field; I use <#bcontributor> in the resource shape for baselines,
and <contributor> for other configuration types.
Nick.
From:
Jad El-Khoury <>
To:
Nicholas Crossley <>
Cc:
""
<>
Date:
01/17/2018 01:16 PM
Subject:
RE: [oslc-domains]
Reconciling 2.0 domain specification base requirements with OSLC Core 3.0
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
,
www.kth.se
From: Nicholas Crossley [mailto:]
Sent: 17 January 2018 15:48
To: Jad El-Khoury
Cc:
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
<>
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 [attachment "Capture.PNG"
deleted by Nicholas Crossley/Seattle/Contr/IBM]
