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 From: Robin Cover <
robin@oasis-open.org > To: Arthur Ryman/Toronto/IBM@IBMCA Cc: Chet Ensign <
chet.ensign@oasis-open.org >, "
oslc-promcode@lists.oasis-open.org " <
oslc-promcode@lists.oasis-open.org >, Robin Cover <
robin@oasis-open.org > Date: 12/05/2014 05:28 AM Subject: Re: [oslc-promcode] Re: Including files in specifications for PROMCODE Hi Arthur, Thanks for providing information about the TC's goals and plans in the use of namespace name URIs, content negotiation, etc. I have lead responsibility on OASIS Staff for advancing our Web architecture best practices and server support, and indeed, I have discussed most of these OSLC-related issues with Steve Speicher [1a]. Please feel free to send email off-list (
robin@oasis-open.org ) if it's sausage-making, or to discuss the TC's plans on-list as a means of providing early notice, so that the proposed naming design or server function can be evaluated. A couple initial comments: 1. With respect to your note below about the use of content negotiation ("The only novel requirement here is that we need to support HTTP content negotiation"): content negotiation is a topic I discussed with the OpenDocument TC members in May 2014, indicating our agreement that we will support content negotiation for applicable (semantic web) resources, as needed. We're on board! I wrote: "We agree that it's expected and necessary to support content negotiation on the OASIS Library server(s) for the Linked Data resources, so we have plans underway to make that happen..." [2a] The memo in [1a] {msg00022.html} mentions "content negotiation" in our framework solution several times, though the initial plans for using HTTP 3** redirects in connection with the open-serivces.net namespace URIs have been altered (reverse proxy)... 2. With respect to the hypothetical ("suppose") examples below which predicate the existence of information resources (files) rooted "at" locations like "
http://docs.oasis-open.org/oslc-promcode/ns/* " , viz., "the content at:
http://docs.oasis-open.org/oslc-promcode/ns/core.html the content at:
http://docs.oasis-open.org/oslc-promcode/ns/core.rdf the content at:
http://docs.oasis-open.org/oslc-promcode/ns/core.ttl " I understand these to be typical hypothetical examples of content negotiation, similar to what we see now on open-services.net , and broadly for SemWeb/linked data [3a]. For planning purposes, and especially if you plan to declare a namespace like "
http://docs.oasis-open.org/oslc-promcode/ns/foo# " (or "
http://docs.oasis-open.org/oslc-promcode/ns/foo " OR "
http://docs.oasis-open.org/oslc-promcode/ns/foo/ " ): we reserve any such path containing /ns/ for constructing identifiers only, and we never store (tangible/file) "content at" a location suggested e.g., by "
http://docs.oasis-open.org/oslc-promcode/ns/core.html ". Please see the Naming Directives for an explanation [
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#ns-pathElementReserved ]. It is OK to use the path with /ns/ to construct identifiers for non-information items (viz., identifiers/names for named properties, classes, functions, dialects, faults, actions, named message types, etc). 3. Thanks for the references to Jazz.net for help. If the .htaccess file you mention is portable (or likely re-usable in part), please send it to me. Thanks, and best wishes, - Robin Cover PS It's encouraging to see the uptake of ReSpec for authoring in the OSLC Member Section (affiliated) TCs, based upon the customizations provided by Steve Speicher. I strongly support that effort, and thank all of you (authors, editors, reviewers) who are assisting in that development effort, despite some (likely) growing pains. Congratulations! *** References: [1a] Issues relating to OSLC URIs/identifiers on open-services.net
https://lists.oasis-open.org/archives/oslc-core/201409/msg00022.html See also:
https://wiki.oasis-open.org/oslc-core/VocabStableURINotes https://lists.oasis-open.org/archives/oslc-core/201409/msg00028.html https://lists.oasis-open.org/archives/oslc-sc/201409/msg00013.html https://lists.oasis-open.org/archives/oslc-sc/201410/msg00013.html [2a] Subject: Question for the TC about resolving the OpenDocument v1.2 namespace URIs From: Robin Cover <
robin@oasis-open.org > To: Michael Stahl <
mstahl@redhat.com > Date: Thu, 8 May 2014 14:46:15 -0500
https://lists.oasis-open.org/archives/office/201405/msg00002.html "We agree that it's expected and necessary to support content negotiation on the OASIS Library server(s) for the Linked Data resources, so we have plans underway to make that happen. We also need to update the mine-types file. I'll communicate with you as the changes are made." Followup (tangential) Question for the TC about resolving the OpenDocument v1.2 namespace URIs [#11216]
https://lists.oasis-open.org/archives/office/201406/msg00011.html [3a] examples of various representations (W3C, WorldCat) ** Case: The namespace for all PROV-O terms is
http://www.w3.org/ns/prov# Client/agent askes for resource at
http://www.w3.org/ns/prov# with the following Accept (HTTP) request headers, and gets: HEADER GETS: text/turtle prov.ttl application/rdf+xml prov.rdf application/xml prov.xsd text/html prov.html application/owl+xml prov.owl
http://www.w3.org/ns/prov.html http://www.w3.org/ns/prov.ttl http://www.w3.org/ns/prov.rdf http://www.w3.org/ns/prov.xsd http://www.w3.org/ns/prov.owl ** Case: from WorldCat bibliographic database Gandhi (Story of my experiments with truth)
http://worldcat.org/entity/work/id/1151002411 Request the work by ID (
http://worldcat.org/entity/work/id/1151002411 ) with various HTTP Accept header requests, and get the corresponding representations, per the needs of the Web agent/client
http://experiment.worldcat.org/entity/work/data/1151002411.ttl http://experiment.worldcat.org/entity/work/data/1151002411.nt http://experiment.worldcat.org/entity/work/data/1151002411.jsonld http://experiment.worldcat.org/entity/work/data/1151002411.rdf http://experiment.worldcat.org/entity/work/data/1151002411.html via named content types: text/turtle application/n-triples application/ld+json application/rdf+xml text/html On Thu, Dec 4, 2014 at 3:39 PM, Arthur Ryman <
ryman@ca.ibm.com > wrote: Chet, Thanks for the description of the process. I am glad to see that this process includes artifacts such as schemas, wsdl, etc. In our TC, we need to publish an RDF vocabulary (and some other RDF files), as will other OSLC TCs. The W3C has published Best Practices for this [1]. The only novel requirement here is that we need to support HTTP content negotiation. This means that we need to serve up different content types for a given URI, based on an Accept header. We've implemented this at OSLC and jazz.net which both use an Apache web server. We created a .htaccess file to generate 303 redirects, which is Recipe 3 [2]. We'd deploy the .htaccess file into our root directory:
http://docs.oasis-open.org/oslc-promcode/ Let me be concrete. Suppose we assign the following URI to our RDF vocabulary:
http://docs.oasis-open.org/oslc-promcode/ns/core When the Accept header contains text/html or application/xhtml+xml we respond with the content at:
http://docs.oasis-open.org/oslc-promcode/ns/core.html When the Accept header contains application/rdf+xml we respond with the content at:
http://docs.oasis-open.org/oslc-promcode/ns/core.rdf When the Accept header contains text/turtle we respond with the content at:
http://docs.oasis-open.org/oslc-promcode/ns/core.ttl [1]
http://www.w3.org/TR/swbp-vocab-pub/ [2]
http://www.w3.org/TR/swbp-vocab-pub/#recipe3 _________________________________________________________ Arthur Ryman Chief Data Officer SWG Rational 905.413.3077 (phone) 416.939.5063 (cell) IBM InterConnect 2015 From: Chet Ensign <
chet.ensign@oasis-open.org > To: Arthur Ryman/Toronto/IBM@IBMCA Cc: Kazuhiro Funakoshi <
k-f@bk.jp.nec.com >, "
oslc-promcode@lists.oasis-open.org " <
oslc-promcode@lists.oasis-open.org > Date: 12/02/2014 10:00 AM Subject: Re: [oslc-promcode] Re: Including files in specifications for PROMCODE Hi Arthur, Here is the process that TCs follow to publish their work. Initially the TC prepares a working draft of the specification. This can be a combination of draft documents, schemas, wsdl files, etc. The TC uses its document repository on its web page, its wiki and its svn to store these elements. TCs do not have write privileges to docs.oasis-open.org . When the TC is ready to assemble the content into an initial working draft of the specification, someone - usually the editor or the chair - requests a starter document from TC Administration using the support request at
https://www.oasis-open.org/resources/tc-admin-requests/work-product-registration-template-request . Among other things this request does is let us work out with you all any details about the final urls and organization of the spec when it is published. The TC uses this starter document to prepare the working draft of the committee spec. We can provide templates in doc or odf format. For TCs that want to publish from their own source in xml, latex, etc. we'll work with you to use this template as a guide to publishing the final form needed. When the TC is ready to publish its first Committee Specification Draft and, if it chooses, release it for its first public review, it passes a motion to approve those steps in a meeting of the TC or by a ballot. The language you can use for the motion can be puled from the template at
https://www.oasis-open.org/committees/download.php/53768 . After that approval is made, someone submits a request to publish the CSD (
https://www.oasis-open.org/resources/tc-admin-requests/committee-specification-draft-creation-upload-request ) and, if desired, the request to start a public review (
https://www.oasis-open.org/resources/tc-admin-requests/committee-specification-draft-creation-upload-request ). TC Administration will then takes your working draft as approved and prepares the corresponding HTML and PDF versions and loads all the components to docs.oasis-open.org . We'll notify the TC when its ready and if a public review is to be started, announce that publicly as well. There are further steps - handling comments from public review, approving a Committee Specification by Special Majority Vote, etc. They are explained here ->
https://www.oasis-open.org/resources/tcadmin/tc-process-how-to-guide-introduction . This should get you started though. Best regards, /chet On Tue, Dec 2, 2014 at 8:15 AM, Arthur Ryman <
ryman@ca.ibm.com > wrote: Chet - As I understand it, our TC decides when to post documents at docs.oasis-open.org/oslc-promcode/.. .. Therefore we can post drafts there. Kaz & TC I think our documents should use the permanent URLs. We can use SVN to work on documents. I think we should post stable versions of documents at docs.oasis-open.org/oslc-promcode/. .. and always include status information in them to indicate if they are drafts, final, etc. _________________________________________________________ Arthur Ryman Chief Data Officer SWG Rational 905.413.3077 (phone) 416.939.5063 (cell) IBM InterConnect 2015 From: Kazuhiro Funakoshi <
k-f@bk.jp.nec.com > To: Chet Ensign <
chet.ensign@oasis-open.org >, Arthur Ryman/Toronto/IBM@IBMCA Cc: "
oslc-promcode@lists.oasis-open.org " <
oslc-promcode@lists.oasis-open.org > Date: 12/01/2014 08:11 PM Subject: RE: [oslc-promcode] Re: Including files in specifications for PROMCODE Sent by: <
oslc-promcode@lists.oasis-open.org > Hi Chet, Thank you for information. Now I understand. Arthur, Do you think we have to make current draft consistent to current URL( I mean at SVN address) ? Best regards, Kaz From:
oslc-promcode@lists.oasis-open.org [ mailto:
oslc-promcode@lists.oasis-open.org ] On Behalf Of Chet Ensign Sent: Tuesday, December 02, 2014 1:37 AM To: Funakoshi Kazuhiro(?? ??) Cc: Arthur Ryman;
oslc-promcode@lists.oasis-open.org Subject: Re: [oslc-promcode] Re: Including files in specifications for PROMCODE Hi Kaz, docs.oasis-open.org/oslc-promcode/. .. is where your approved TC work products will be loaded and managed once the TC begins approving Committee Specification Drafts, public reviews and the like. The working drafts you produce prior to that step belong in your document repository or in the SVN. Best, /chet On Thu, Nov 27, 2014 at 1:17 AM, Kazuhiro Funakoshi <
k-f@bk.jp.nec.com > wrote: Arthur, OK, I did it. I agree with you. Cleaner URLs are needed. Thank you in advance for stable URL information. I use the repository is not for publishing but for version control among our TC members. Using wiki cannot manage versions with multiple wiki pages. So basically, I will also publish at wiki at some milestones of drafts. We can choose using document repository( doc.oasis-open.org ) or wiki for publish, or whatever OASIS recommends. -- Kaz
Original Message----- From: oslc-promcode@lists.oasis-open.org [mailto: oslc-promcode@lists.oasis-open.org ] On Behalf Of Arthur Ryman Sent: Thursday, November 27, 2014 4:10 AM To: Chet Ensign; oslc-promcode@lists.oasis-open.org Cc: Steve K Speicher Subject: [oslc-promcode] Re: Including files in specifications for PROMCODE Chet - Thx. Kaz - Please also upload the generated Turtle files to SVN. I only see the generated HTML. This gives us stable URLs, e.g. for HTML: https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/shape /trunk/Project.html for Turtle: https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/shape /trunk/Project.ttl However, we should really define cleaner URLs and set up HTTP redirects from those to the SVN URLs. The redirects should also handle content negotiation. We did this on the OSLC website for RDF vocabulary documents. Steve pointed out that OASIS did have a mechanism for assigning cleaner URLs. I will follow up on that. _________________________________________________________ Arthur Ryman Chief Data Officer SWG Rational 905.413.3077 (phone) 416.939.5063 (cell) IBM InterConnect 2015 From: Chet Ensign < chet.ensign@oasis-open.org > To: Arthur Ryman/Toronto/IBM@IBMCA Date: 11/26/2014 01:36 PM Subject: Re: Including files in specifications for PROMCODE HI Arthur, We don't permit attachments on our wiki as doing so would likely have system and cost impacts that we can't afford. For stable URLs, I suggest that you use the PROMCODE SVN system at https://tools.oasis-open.org/version-control/browse/wsvn/oslc-promcode/?sc=0 . That is what other TCs use for the same purpose. Best, /chet On Tue, Nov 25, 2014 at 12:16 PM, Arthur Ryman < ryman@ca.ibm.com > wrote: Chet, We are producing some files as part of the spec. We want to assign stable URLs to these files. I normally do this at OSLC using wiki attachments. That capability seems to turned off at PROMCODE. What is the best practice at OASIS (e.g. for XML schemas, WSDL)? Can we get file attachments enabled in our wiki? Thank. _________________________________________________________ Arthur Ryman Chief Data Officer SWG Rational 905.413.3077 (phone) 416.939.5063 (cell) IBM InterConnect 2015 -- /chet [§] ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission- checklist.html TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open --------------------------------------------------------------------- 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 -- /chet [§] ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open --------------------------------------------------------------------- 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 -- /chet [§] ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open --------------------------------------------------------------------- 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: robin@oasis-open.org 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 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org 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