Review of Overview document

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:

Missing required configuration: revision
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.

Status:

~~Current in progress editor's draft, expect change.~~

Section 1

This has resulted in ~~strong~~ demand... (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.

Section 3

OSLC Server: defined by at least one OSLC-based specifications.

OSLC Domain Specifications: I think it should also mention existing non-OASIS specifications. Not sure exactly how to say it however.

Section 3.1

... any more (needs a space)

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.

Section 5

Some scenarios[,] require the need to... (remove comma)

For these scenarios the technology is evolving rapidly.

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.

Section 6.1

and providing meta[-] data to tools that handle RDF data such as form and query builders. (moved clause, remove dash)

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"?)

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

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?

Section 6.10

... particularly useful in handling results from the query capability or listing contents of an LDP container.

oslc-core message