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

[Kazuhiro Funakoshi <k-f@bk.jp.nec.com>]

Arthur,

Let me confirm the expected changes. Because I could not understand your 
intention of the E-mail to Robin Cover very well.

(1)
Our shape document should have @base address like [1] which redirects to real 
files [2] in case of text/turtle, and [3] in case of text/html. Therefore each 
of @base address should be [3].

[1] https://doc.open-services.net/oslc-promcode/ns/shape/Artifact
[2] 
https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/shape/trunk/Artifact.ttl
[3] 
https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/shape/trunk/Artifact.html
[4] https://doc.open-services.net/oslc-promcode/ns/shape/

(2)
Can I change these as:
[1'] https://doc.open-services.net/oslc-promcode/ns/shape#Artifact
[2] 
https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/shape/trunk/Artifact.ttl
[3'] 
https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/shape.html#Artifact
[4'] https://doc.open-services.net/oslc-promcode/ns/shape#

I would prefer to generate single html document for shape.html and redirect 
request like [1] as [2] or [3'], rather than Artifact.html or WorkItem.html.
The reason is that ReSpec seems to generate entire document in single html 
with a big header and it is not suitable for each documents about individual 
resource shapes.
And no change to resource shape files [2], they are individual ttl files about 
individual resource shape.
Is this able to be done with .htaccess file as well?

-- 
Kaz


From: oslc-promcode@lists.oasis-open.org 
[mailto:oslc-promcode@lists.oasis-open.org] On Behalf Of Robin Cover
Sent: Saturday, December 06, 2014 3:04 AM
To: Arthur Ryman
Cc: oslc-promcode@lists.oasis-open.org; Robin Cover
Subject: Re: [oslc-promcode] Re: Including files in specifications for 
PROMCODE

On Fri, Dec 5, 2014 at 9:30 AM, Arthur Ryman <ryman@ca.ibm.com> wrote:
Robin,

Thanks for the information. I confess to have not previously read
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#ns-pathElementReserved
.  I agree that we shouldn't store the actual information resources in the
/ns path. In fact, at jazz.net all the information resources are stored in
our wiki and the .htaccess file redirects to it.

OK, great.

I read the OASIS Naming Directives. RDF vocabularies are Work Products,

Whether a single "RDF Vocabulary" is itself a(n entire) "Work Product" or 
whether its variant representations may be constituent parts of a Multi-Part 
Work Product [ 
https://www.oasis-open.org/policies-guidelines/tc-process#quality-multiPart ] 
can be clarified, but I think the "Vocabulary" would be a "part" or 
represented in 2+ "parts"  [1b]

but they are computer language definitions, so we'd use a fixed filename,
e.g. core.rdf, and put the various stages at different paths

Whether every representation of an OSLC vocabulary is a "computer language 
definition": unsure, but I'd think some are and at least one is probably now.

But no matter: we can indeed expect fixed filenames for actual files (bits) on 
a file system, similar to the three examples for files below

, e.g. for
v1.0, Working Draft revision 01, the three representations of
http://docs.oasis-open/oslc-promcode/ns/core# would have the following
URIs:

http://docs.oasis-open.org/oslc-promcode/core-vocab/v1.0/wd01/core.rdf
http://docs.oasis-open.org/oslc-promcode/core-vocab/v1.0/wd01/core.ttl
http://docs.oasis-open.org/oslc-promcode/core-vocab/v1.0/wd01/core.html

It this correct?

In the abstract: yes, that seems correct, modulo a couple nits

a) the OASIS Library is not used for Working Draft level content [2b]

b) I'd need more explanation/description to understand the notion of the three 
resources (files) being "representations of" the namespace URI, if you mean 
anything other than that dereferencing the NS URI with variable Accept headers 
will result in Web delivery of different "representations" (of the vocabulary) 
associated with the namespace URI... I think that's what you mean.


I'll send you the details of .htaccess for jazz.net off-list.

Perfect, and thanks!   We welcome your assistance in the process of upgrading 
our web server functionality to support SemWeb /LOD expectations.

_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015




[1b] 
http://open-services.net/wiki/core/Vocabulary-index/#Vocabularies-and-Specifications

Specification (HTML): 
http://open-services.net/bin/view/Main/OslcCoreSpecification
Namespace name: http://open-services.net/ns/core#
RDF Schema (.rdf): http://open-services.net/ns/core/core.rdf
Vocabulary "OslcCoreVocabulary": 
http://open-services.net/bin/view/Main/OslcCoreVocabulary
 (HTML may be generated from .rdf or .ttl vocabulary file via XSLT)

[2b] On Working Draft: the Naming Directives document recommends and 
illustrates the use of revisioning identifers (01, 02, 03) in connection with 
content released/published at Working Draft level, when such identifiers are 
natural in the spec development process.  However, since content at Working 
Draft level is not TC "Approved" work, we do not publish Working Drafts in the 
OASIS Library, per the definition [ 
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#dfn-OASIS-Library ] 
.   OASIS TCs are welcome to use wd01, wd02, wd02 when uploading content to 
the TC's Kavi repository (similarly to the TC discussion list, Wiki, version 
control system), but since those venues have their own native version-control 
identifier schemes, many TCs don't use "wd01" etc.  Kavi, for example, uses 
something it calls "revisions", starting with the natural counting number zero

Thus, if you inspect examples in the OASIS Library, you should not see 
releases with the identifier component "wd", but Work Product lifecycle 
progressions that begin with "csd01" (Standards Track):

http://docs.oasis-open.org/tosca/TOSCA/v1.0/
 (CSD01 to OS)
http://docs.oasis-open.org/camp/camp-spec/v1.1/
 (CSD01 to CS01)

TC Process clarifies that the approval process begins with "Committee 
Specification Draft" (CSD):
Approval Process (progression of Standards Track Work Products))
https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess

Aside: I think the TC Process definition for Working Draft is borked 
(perpetually causes confusion), but see:
"Working Draft" Definition
https://www.oasis-open.org/policies-guidelines/tc-process#dWorkingDraft








Unfortunately, varying statements about "Working Draft" and TC

Attachment: smime.p7s
Description: S/MIME cryptographic signature