Re: [oslc-core] "Vocab" section & wording tweaks. Re: [oslc-core] OSLC Core 3.0 - Overiew **PLEASE REVIEW by January 22nd**

[Steve K Speicher <sspeiche@us.ibm.com>]

Hi Martin,

Thanks for the feedback.  Comments below

> From: Martin P Pain <martinpain@uk.ibm.com>
> To: Steve K Speicher/Raleigh/IBM@IBMUS
> Cc: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 01/21/2015 04:59 AM
> Subject: [oslc-core] "Vocab" section
& wording tweaks. Re: [oslc-core] OSLC 
> Core 3.0 - Overiew **PLEASE REVIEW by January 22nd**
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> Hi Steve, 
> 
> Looks good on the whole. 
> 
> 
> 
> I'm not quite sure I understand the intention of this statement: "Domain
> specifications should simply be domain vocabularies and ontologies,
> leveraging protocol capabilities defined by W3C LDP." 
> Saying "should simply be vocabularies" sounds like you're
suggesting that 
> the vocabs do not exist separate from the specs, but that would seem
to go 
> against lessons learned from 2.0, and also against the sentence "Domain
> vocabulary terms should be developed with global reuse in mind."
> It sounds like it's trying to place a restriction on what should be
in a 
> spec (the word "simply" makes it sound like it's giving
an exhaustive list -
> maybe it is) but the word "leveraging" is quite vague as
to what would 
> actually be in the spec document, and it doesn't mention resource
shapes, 
> which are then referred to a couple of sentences later. 
> 
> Was the intention something along the lines of: 
> "Various OASIS OSLC affiliated TCs, or any specification development
body 
> that is authoring specifications for specific domains of knowledge,
will 
> minimally define vocabularies and the semantics behind the various
terms. 
> Domain specifications are the definition of an OSLC capability, and
how 
> those vocabulary terms are used in HTTP/LDP interactions by both the
clients
> and servers of that capability. This will include defining resource
shapes 
> that describe resources based on a set of vocabulary terms, which
introduces
> any domain specific constraints on the vocabulary's usage. Domain
vocabulary
> terms should be developed with global reuse in mind. Some global reuse
> considerations are when terms are used for cross domain queries and
within 
> other domain resource shape definitions."
> 
I agree with your points. They are in line with this
section was trying to
accomplish. I have mostly taken your proposed wording,
with only minor changes.

> 
> And a few minor things: there are also a few places where the wording
seems 
> a little strange to me, but that might just be a case of taste: 
> e.g. 
> "sufficient yet only necessary aspects " could be "sufficient
aspects - yet 
> only those that are necessary" 

I agree this could be improved, I've tried something
different though.

> "These specifications are motivated and sometimes based on best
practices  
> and on the work of other OSLC Member Section(MS)-affiliated TCs"
perhaps 
> "These specifications have emerged from the best practices and
other work of
> other OSLC Member Section(MS)-affiliated TCs" 

changed

> "an updated set of specifications that are: simpler, have layered
> capabilities and easier to adopt." -> "an updated set
of specifications 
> that: are simpler, have layered capabilities and are easier to adopt."

changed

> "The architecture needs to support scenarios
where there needs to be a 
> protocol to access, create, update and delete resources: which HTTP
is the 
> foundation for this [HTTP11]" maybe "The architecture needs
to support 
> scenarios where there needs to be a protocol to access, create, update
and 
> delete resources: where HTTP is the foundation for this [HTTP11]"
or 
> "resources: HTTP is the foundation for this [HTTP11]" or
"resources: which 
> is HTTP [HTTP11]" 
> And the same with the RDF sentence. 
> 

changed

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net


> 
> Martin 
> 
> 
> 
> From:        Steve K Speicher <sspeiche@us.ibm.com>
> To:        "OASIS OSLC Core TC Discussion
List" <oslc-core@lists.oasis-open.org> 
> Date:        08/01/2015 16:05 
> Subject:        [oslc-core] OSLC Core 3.0 - Overiew
**PLEASE REVIEW by January 22nd**
> Sent by:        <oslc-core@lists.oasis-open.org>
> 
> 
> 
> All, 
> 
> It would be very good to get everyone to review the "OSLC Core
3.0 - 
> Overview" draft [1]. 
> 
> It is intended for all audiences: spec writers, those new to OSLC,
etc.  It 
> is intentionally short too.  It will also serve as the "cover
letter" (if 
> you will) to all 3.0 capability specs. 
> 
> I'd appreciate any feedback: missing content needed, clarity in areas
or 
> even that it has hit the mark and no changes needed. 
> Please try to get it to me by January 22nd. 
> 
> [1]: http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/
> specs/oslc-core-v3.html 
> 
> Thanks in advance,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> http://open-services.net
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU