OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-promcode message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oslc-promcode] Re: Including files in specifications for PROMCODE


[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

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 tc-admin@lists.oasis-open.org 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:

Previous version: [N/A]

Latest version:

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/



7. The goal here is to support efficient and timely coordination between the OSLC TCs and OASIS Staff.


- Robin

On Thu, Dec 18, 2014 at 2:04 AM, Kazuhiro Funakoshi <k-f@bk.jp.nec.com> wrote:

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

However, I have to change shape resource name, I think.
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>,

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


-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com]
Sent: Thursday, December 18, 2014 3:46 AM
To: Funakoshi Kazuhiro(船越 和大)
Cc: robin@oasis-open.org; oslc-promcode@lists.oasis-open.org; Steve K
Subject: RE: [oslc-promcode] Re: Including files in specifications for


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:


The latest version URIs would be:

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: robin@oasis-open.org
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]