Robin/Steve,
I think an OSLC Core TC recommendation would be best. Let's establish the
guidance for RDF vocabularies and resource shapes there. PROMCODE will
follow that. However, let's do this asap since PROMCODE is producing these
artifacts now.
_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015
From: Robin Cover <>
To: Kazuhiro Funakoshi <>
Cc: Arthur Ryman/Toronto/IBM@IBMCA,
"" <>,
Steve K Speicher <>, Robin Cover
<>, Chet Ensign <>, Paul
Knight <>
Date: 12/18/2014 11:09 AM
Subject: Re: [oslc-promcode] Re: Including files in specifications
for PROMCODE
Re:
[Kaz, below, said]
> [3]
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/artifactshape.ttl
1. Thank you for including me as recipient in the email messages if the
PROMCODE TC wants to continue discussion of Work Product URIs in the
current fashion (on the TC list). I will do my best to track your ideas,
but at this point, I feel the conversation has become a bit unwieldy, and
I would like to know if your team leads in OSLC Core and other related TCs
would want to stand up a task force to clarify further your plans for the
related OSLC Work Products. Evaluating successions of proposals from
several parties (piecemeal) seems sub-optimal on several counts. Steve:
have I overlooked updates in Wiki documents which may be relevant here?
2. I discussed the current situation with Chet Ensign, and we believe it's
important for you (all) to use the online form for requesting a Work
Product "template" in connection with each proposed Work Product:
Register & request a Work Product template / starter document
https://www.oasis-open.org/resources/tc-admin-requests/work-product-registration-template-request
3. Using the online form to request a "starter document" (or the
equivalent [ReSpec-based authoring]) will help Staff understand and
evaluate your plans, or seek clarifications as may be needed. That is:
information you provide in the form fields will help us determine whether
the specification design is on track with respect to OASIS expectations
(TC Process, Naming Directives, publication issues). The online form does
not support requests for templates applicable to Multi-Part Work Products,
so if your proposed specification is Multi-Part, please send email to
with proposal details.
4. With respect to the URI reference nominated and quoted above ( "[3]" ):
it's not quite what I would expect for a Work Product that has a Work
Product Abbreviation [WP-abbrev] = "artifactshape". That URI reference
implies a Work Product with title something like "OSLC Artifact Shapes",
and a primary prose specification document with a cover page that provides
the "Document URIs" as follows for the initial approved release:
This version:
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/csd01/artifactshape-v1.0-csd01.html
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/csd01/artifactshape-v1.0-csd01.pdf
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/csd01/artifactshape-v1.0-csd01.docx
Previous version: [N/A]
Latest version:
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/artifactshape-v1.0.html
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/artifactshape-v1.0.pdf
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/artifactshape-v1.0.docx
5. Our default expectation is that a file like "artifactshape.ttl" would
not be stored directly in the "v1.0" directory nor that we would use a URI
alias to make it appear so in the resource URI. We typically want to
keep the "v1.0" directory clean, presenting the URI references for
successive releases (csd01, csd02...) and for the "Latest version:"
formats (for the Work Product as a whole).
6. The clarification above may be inconsequential ultimately (because no
significant commitment is being made at this time), but it serves as an
example to motivate a dedicated focus upon the proposed Work Products and
their structure/composition, especially if any of your proposed Work
Products are "Multi-Part" (having independently titled prose documents: ca
Overview/Intro, Part1, Part2, Part3...). See the emix spec v1.0 directory
for an example of a clean directory:
http://docs.oasis-open.org/emix/emix/v1.0/
Multi-Part
https://www.oasis-open.org/policies-guidelines/tc-process#quality-multiPart
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#URIs-MP
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#filenameSyntaxMP
7. The goal here is to support efficient and timely coordination between
the OSLC TCs and OASIS Staff.
Thanks!
- Robin
On Thu, Dec 18, 2014 at 2:04 AM, Kazuhiro Funakoshi <>
wrote:
Arthur,
I'm fine to do that as long as [1] redirects to these paths.
Since each of rdf(and ttl) has @base as [1] and it redirects to the path
as
you wrote respectively, I don’t need to care about path at this moment, do
I?
However, I have to change shape resource name, I think.
e.g.
Currently(in our WebSVN version), Artifact shape resource has stable path
as
[2] (I assume [2] will be redirected to [3] in case of turtle/text).
The minimum work should be:
* change the name Artifact.ttl into artifactshape.ttl
* change <Artifact> to <artifactshape>
* change <Artifact#isPartOf> to <artifactshape#isPartOf>,
right?
I will do this change after next TC conf next week.
[1] http://open-services.net/ns/promocode/shapes/1.0/shape
[2] http://open-services.net/ns/promcode/shapes/1.0/shape/Artifact
[3]
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/artifactshape.tt
l
--
Kaz
-----Original Message-----
From: Arthur Ryman [mailto:]
Sent: Thursday, December 18, 2014 3:46 AM
To: Funakoshi Kazuhiro(船越 和大)
Cc: ; ; Steve K
Speicher
Subject: RE: [oslc-promcode] Re: Including files in specifications for
PROMCODE
Kaz,
The rules for URIs are described in [1]. That document explains how to
build
up the URI. One of the components of the URI is called work product
abbreviation, WP-abbrev. We therefore need to define a WP-abbrev for each
work product, e.g. each shape file.
I suggest we use the following WP-abbrevs for shape documents:
projectshape
artifactshape
workitemshape
scopeitemshape
etc.
The latest version URIs would be:
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape.rdf
http://docs.oasis-open.org/oslc-promcode/artifactshape/v1.0/artifactshape.rd
f
http://docs.oasis-open.org/oslc-promcode/workitemshape/v1.0/workitemshape.rd
f
http://docs.oasis-open.org/oslc-promcode/scopeitemshape/v1.0/scopeitemshape
.
rdf
If you prefer, you can use camel case, e.g. ProjectShape.
Robin - please confirm I have this right. Thx.
[1] http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html
_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell) IBM InterConnect 2015
--
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email:
Staff bio: http://www.oasis-open.org/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783
