[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, 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: "oslc-promcode@lists.oasis-open.org" <oslc-promcode@lists.oasis-open.org> > Cc: Steve K Speicher/Raleigh/IBM@IBMUS, robin@oasis-open.org > 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] > > <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 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: 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, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]