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,

Originally I thought we would use the oasis-open.org domain for URIs. 
However, I talked with Robin and Steve and the thinking now is that since 
we already have a lot of vocabularies on the open-services.net domain, we 
should continue to use that. I've asked Steve to post an official policy 
statement to this mailing list, which he will do as soon as he gets 
access. Here is my summary.

The PROMCODE core vocabulary URI will be:
http://open-services.net/ns/promcode#

This URI never changes as we evolve the vocabulary in later versions. We 
just add more terms. We do not change the names or meanings of existing 
terms

We will configure the open-services.net server to redirect to the latest 
version on docs.oasis-open.

We will host the approved versions of the vocabulary documents on 
docs.oasis-open. There are OASIS naming directives [1] that we have to 
follow. For example, the latest version would be at:
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/corevocab-v1.0.rdf
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/corevocab-v1.0.ttl
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/corevocab-v1.0.html

In addition to the latest version, we also publish each approved revision 
of each stage, e.g. for Committee Specification Draft, revision 04:
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/csd04/corevocab-v1.0-csd04.rdf
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/csd04/corevocab-v1.0-csd04.ttl
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/csd04/corevocab-v1.0-csd04.html

We do a similar thing for shape documents. One difference is that it makes 
sense to change their URI since the URI identifies the document as a whole 
instead of terms within the document.

The shape document for Project resources will be:
http://open-services.net/ns/promocode/shapes/1.0/project

This will redirect to the latest version:
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape-v1.0.rdf
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape-v1.0.ttl
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape-v1.0.html

You asked if you could put all the HTML shapes in one document. In that 
case we would publish its latest version at:
http://docs.oasis-open.org/oslc-promcode/shapes/v1.0/shapes-v1.0.html

And we would redirect HTML requests on 
http://open-services.net/ns/promocode/shapes/1.0/project to
http://docs.oasis-open.org/oslc-promcode/shapes/v1.0/shapes-v1.0.html
#project


[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


<oslc-promcode@lists.oasis-open.org> wrote on 12/15/2014 11:54:56 PM:

> From: Kazuhiro Funakoshi <k-f@bk.jp.nec.com>
> To: Arthur Ryman/Toronto/IBM@IBMCA
> Cc: "oslc-promcode@lists.oasis-open.org" 
<oslc-promcode@lists.oasis-open.org>
> Date: 12/15/2014 11:56 PM
> Subject: RE: [oslc-promcode] Re: Including files in specifications 
> for PROMCODE
> Sent by: <oslc-promcode@lists.oasis-open.org>
> 
> 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 ofthe 
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



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