Re: [oslc-core] Review of Overview document

["Jim Amsden" <jamsden@us.ibm.com>]

Martin,
Comments embedded below as usual in
<jra> tags.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 "Sarabura, Martin"
<msarabura@ptc.com>
To:      
 "OSLC Core TC
(oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date:      
 01/31/2016 04:01 PM
Subject:    
   [oslc-core]
Review of Overview document
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/oslc-core.html
 
Jim, just a few minor alterations here
plus a question for section 6.9.1. Most importantly, when I loaded the
document into my FF browser I got ReSpec 2 in the upper right corner, with
error messages:

1. Missing required configuration: revision
2. Error loading references from 'https://specref.jit.su/bibrefs?refs=RFC2119,LDP,OSLCCore2,WEBARCH,HTTP11,Turtle,LDBestPractices,rdf11-concepts,HTML5,SHACL,rfc6749,OpenIDConnect,SPARQL': error ()

As a result I was unable
to confirm the internal reference hyperlinks. When the ReSpec problem is
fixed I'll check each of the hyperlinks.

<jra>You probably saw
this morning that Nick has fixed this.</jra>
 
Status:
Current in progress editor's draft,
expect change.
 
Section 1
This has resulted in strongdemand... (don't think we need the adjective)
... there is a need for a sufficient supporting
architecture that is[:] loosely coupled... (remove colon)
Second paragraph: Nonetheless, it can be
used by tools belonging to any other domains and cross-domain
scenarios.
and perhaps some examples: , for example
Internet of Things, back office applications, and customer relationship
management.
<jra>fixed</jra>
 
Section 3
OSLC Server: defined by at least oneOSLC-based specifications.
OSLC Domain Specifications: I think it
should also mention existing non-OASIS specifications. Not sure exactly
how to say it however.
<jra>...including
existing open-services.net specifications and new specifications created...</jra>
 
Section 3.1
... any more (needs a space)
<jra>fixed</jra>
 
Section 4.
New capabilities related to traceability
and impact types? I don't recall those particular improvements - perhaps
you can provide links? Might be a good idea to add links for Attachments
and inverse link labels too.
Inverse link labels should not be capitalized.
<jra>They're in core
vocabulary. Links are provided in a later section, this is a quick introduction.</jra>
 
Section 5
Some scenarios[,] require the need to...
(remove comma)
For these scenarios the technology is evolving
rapidly.
<jra>fixed</jra>
 
Section 6
Mark this section non-normative
Although OSLC Core could be useful on its
own... Really? I think it has value only in the context of a domain, even
if that domain is not an officially published domain.
<jra>Not sure if a
section is marked non-normative, then its subsection inherit that designation.
I marked it non-normative and assume that any subsection that is not marked
is considered normative.</jra>

Section 6.1
and providing meta[-] data to tools that
handle RDF data such as form and query builders. (moved clause, remove
dash)
<jra>fixed</jra>
 
Section 6.4
First section is non-normative
... in concert with existing industry standards
and which offer consistency...
... have adopted the convention to illustrate
scenarios using Turtle and JSON-LD... (also, is it true that both are
used? Should it say "and optionally JSON-LD, or "and/or JSON-LD"?)
<jra>fixed
...the convention to illustrate most
examples using Turtle and/or JSON-LD representations...</jra>
 

Section 6.9
... projection of desired properties...
(should you say filtering rather than projection?)
Ofter time, Eventually
that may lead to the deprecation of OSLC Core 2.0 Query Capability
<jra>fixed (filtering,
yes)</jra>
 
Section 6.9.1
What about discoverability of the query
syntax? How do you know whether the server supports OSLC 2 query, or SPARQL,
or any other future query ability?
<jra>OSLC doesn't define
discovery of query syntax, it only supports one syntax. If/when this changes,
then some discovery mechanism might be required.</jra>

Section 6.10
... particularly useful in handling results
from the query capability or listing contents of an LDP container.
<jra>fixed</jra>