Kaz,
I forgot that vocabularies and shapes are "computer language definitions".
Therefore we can use simpler URLs, e.g. the latest versions would be
posted at:
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/corevocab.rdf
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/corevocab.ttl
http://docs.oasis-open.org/oslc-promcode/corevocab/v1.0/corevocab.html
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/
projectshape.rdf
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/
projectshape.ttl
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/
projectshape.html
_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015
Arthur Ryman/Toronto/IBM wrote on 12/16/2014 11:49:48 AM:
> From: Arthur Ryman/Toronto/IBM
> To: ""
<>
> Cc: Steve K Speicher/Raleigh/IBM@IBMUS,
> Date: 12/16/2014 11:49 AM
> 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
> [image removed]
>
> <> wrote on 12/15/2014 11:54:56 PM:
>
> > From: Kazuhiro Funakoshi <>
> > To: Arthur Ryman/Toronto/IBM@IBMCA
> > Cc: "" <oslc-
> >
> > Date: 12/15/2014 11:56 PM
> > Subject: RE: [oslc-promcode] Re: Including files in specifications
> > for PROMCODE
> > Sent by: <>
> >
> > 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
andredirect
> > 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:
> > [mailto:] On Behalf Of Robin Cover
> > Sent: Saturday, December 06, 2014 3:04 AM
> > To: Arthur Ryman
> > Cc: ; Robin Cover
> > Subject: Re: [oslc-promcode] Re: Including files in specifications for
> > PROMCODE
> >
> > On Fri, Dec 5, 2014 at 9:30 AM, Arthur Ryman <> 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, ifyou
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
