Re:
> Hi Robin,
>
> (2) above also has been discussed, right?
> Is it a correct behavior that v1.0 shapes refer to v2.0 or newer vocabulary?
Kaz,
Your question in the context of this thread seems to relate to the notion of "Version" with respect to the OASIS identifier schemes -- and not to vocabulary "versions" under a (different) open-services.net versioning scheme ... right? Assuming that you mean OASIS "Version", I'll try to clarify how we use namespace name identifiers and versioning
* Version: http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#Version
A "Version" is identified with a unique Work Product, used in all releases for the specification lifecycle for that Work Product ( WD, CSD, CS, COS, OS). Once the Work Product comes to CS or OS (OASIS Standard) level (or is abandoned), that "Version" is complete.
While a Work Product is progressed through its lifecycle, namespace name identifiers can also be revisioned (e.g., incremented using numeric components in sequence), per the wishes of the TC
The Naming Directives document clarifies that for namespace URIs using the docs.oasis-open.org domain ( pattern: http://docs.oasis-open.org/[tc-shortname]/ns/xxxx ), the final "xxxx" should ( should, not must) "incorporate a versioning subcomponent (e.g., a string like 201011 representing a date or v1.1 representing a version number)". In the case of the OSLC specs, where legacy namespace name URIs and construction patterns are being used, the OASIS guidance about "versioning subcomponent" is not directly applicable
If the TC wants to use a namespace name URI for a spec that applies to more than one Version of the specification (e.g., http://open-services.net/ns/promcode# ) -- that should be OK as far as I know. Whatever URI aliasing machinery is set up to deliver the correct representation from the OASIS server when the "open-services.net" URI reference is dereferenced -- should fetch/deliver whatever the TC elects. In the case of traditional OASIS specs, namespace name URIs have often been versioned (per Naming Directives "should") in support of a TC's goals for implementation, conformance, etc. But if you don't want to (verbatim) version your namespace names, I think that's up to you, per SemWeb expectations
Irrespective of the above, the use of "Latest version:" URIs is scoped to a particular OASIS "Version". That's orthogonal to the conventions your TC may want to use in versioning or nor versioning a namespace name URI
How OASIS "Latest version:" URIs work in the case of "Versions": the KMIP Profiles will illustrate the point: "Latest" is bound to one Version, and does not cross Versions
http://docs.oasis-open.org/kmip/profiles/
http://docs.oasis-open.org/kmip/profiles/v1.0/
http://docs.oasis-open.org/kmip/profiles/v1.1/
http://docs.oasis-open.org/kmip/profiles/v1.2/
A couple more clarifications below:
On Tue, Dec 16, 2014 at 7:05 PM, Kazuhiro Funakoshi <> wrote:Arthur,
Thank you for information.
I will change current our shape document as you told me.
(1)
However, the following lines seems not correct, does it?
>
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
In the case of a Work Product "projectshape", we expect for the version-specific (per release) identifiers:
[Release]
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/csd01/projectshape-v1.0-csd01.html
Latest:
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape-v1.0.html
per:
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#paths
http://docs.oasis-open.org/[tc-shortname]/[WP-abbrev]/[version-id]/[stage-abbrev][revisionNumber]/[doc-id].[ext]
Hope that helps. If not, or if I messed up something (on too little sleep), please let me know.
- Robin
They should be:
>
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/{Artifact,WorkIte
m,ScopeItem,Issue,etc}.{rdf,ttl}
>
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape.html
I will change our shape document in WebSVN as once they are approved, then
we can simply copy from WebSVN to docs.oasis-open.org.
(2)
When we have v2.0, if we use [1] as stable @prefix for v1.0 shape document
it will means v1.0 shape documents uses v2.0 vocabulary document, because
[1] redirect to v2.0 vocabulary document.
I understand we will never change existing v1.0 content but only extend as
v2.0, still confusing.
This wouldn't happen for shape document because it seems not have stable
redirect URL between major versions as you said:
> The shape document for Project resources will be:
> http://open-services.net/ns/promocode/shapes/1.0/project
Is my understanding correct?
[1] http://open-services.net/ns/promcode#
Hi Robin,
(2) above also has been discussed, right?
Is it a correct behavior that v1.0 shapes refer to v2.0 or newer vocabulary?
--
Kaz
-----Original Message-----
From:
[mailto:] On Behalf Of Arthur Ryman
Sent: Wednesday, December 17, 2014 2:36 AM
To:
Cc: Steve K Speicher;
Subject: RE: [oslc-promcode] Re: Including files in specifications for
PROMCODE
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#projec
t
>
> [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.r
> > df
> > http://docs.oasis-open.org/oslc-promcode/core-vocab/v1.0/wd01/core.t
> > tl
> >
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
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
