Re: [oslc-core] Re: OSLC specifications at OASIS: namespace processing and Linked Data server/client behaviors

[Martin P Pain <martinpain@uk.ibm.com>]

(I've added my summary of the options to
the wiki - feel free to edit to make them more balanced/less biased if
needed)



Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical
committee chair

E-mail: martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

<oslc-core@lists.oasis-open.org> wrote on 01/05/2014
11:16:07:

> From: Martin P Pain/UK/IBM@IBMGB
> To: Steve K Speicher <sspeiche@us.ibm.com>,

> Cc: Chet Ensign <chet.ensign@oasis-open.org>,
Arnaud Le Hors 
> <lehors@us.ibm.com>, Nick Crossley <ncrossley@us.ibm.com>,
OASIS 
> OSLC Core TC Discussion List <oslc-core@lists.oasis-open.org>,
Paul 
> Knight <paul.knight@oasis-open.org>, Robin Cover <robin@oasis-
> open.org>, Sean Kennedy <seanpk@ca.ibm.com>, Samuel Padgett
> <spadgett@us.ibm.com>
> Date: 01/05/2014 11:16
> Subject: Re: [oslc-core] Re: OSLC specifications
at OASIS: namespace
> processing and Linked Data server/client behaviors
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> My two cents: 
> 
> I see the following two things as things we should avoid: 
> A. HTTP redirects between open-services.net and OASIS on NS URIs 
> (for the reasons already raised - confusion over which is the primary
URI) 
> B. Copying existing vocabularies from open-services.net to OASIS 
> (for the reasons already raised - breaking backwards compatibility)
> 
> Which I think leaves us with two options:
> 
> 1. Any changes to existing vocabularies (new terms, deprecations,
> improved/widened descriptions) are submitted back to one or more 
> working groups at open-services.net (the Core WG, probably) which
is
> just there to accept such changes. These vocabularies are then 're-
> used' by the specs at OASIS. (One benefit of this is that the 
> contents of the vocabulary might get review separately from the spec
> itself, encouraging a higher quality of vocabulary). Any entirely
> new vocabularies can be in the OASIS domain and hosted on OASIS. The
> main problem, as far as I can see, is that the governance and 
> longevity/persistence of those vocabularies does not come with 
> OASIS's guarantees, as they are neither owned nor managed by OASIS.
> But this isn't unique to the OSLC vocabulaies - as we already re-use
> other vocabularies too - LDP, RDF itself, etc. (But then again, W3C
> has stronger governance than open-services.net) 
> 
> 2.  The open-services.net domain name and the management of the
NS 
> documents (but possibly not the wiki & community content) is 
> transferred to OASIS. OASIS specs can then add to these 
> vocabularies, and define new ones under this domain (although we 
> could still choose to use oasis-open.org for new ones, if we 
> prefer), with OASIS being responsible for their governance and 
> longevity/persistence. 
> 
> I think these two options cover all the scenarios that are on the
> wiki page (although maybe not all the OASIS guidelines), excluding
> the options that use either of the things from the "avoid"
list above. 
> Can anyone see anything that isn't included in these two options?
> 
> I've presented this in terms of 2 options, so if we want we can 
> focus on the viable options, rather than spending 'unnecessary' time
> discussing things like the pros and cons of HTTP redirects. (It's
> pretty much writing out exactly my understanding of the wiki, but
as
> a cross-section of the options across the scenarios, so we can see
> it from two perspectives: the scenarios, and the solutions.) 
> 
> 
> Martin Pain
> Software Developer - Green Hat
> Rational Test Virtualization Server, Rational Test Control Panel
> OASIS Open Services for Lifecycle Collaboration - Automation 
> technical committee chair 
> 
> E-mail: martinpain@uk.ibm.com
> Find me on: [image removed]  and within IBM on: [image removed]
  
> 
> [image removed] 
> 
> 
> 
> 
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6
3AU 
> 
> 
> 
> From:        Steve K Speicher <sspeiche@us.ibm.com>
> To:        Robin Cover <robin@oasis-open.org>,
> Cc:        Arnaud Le Hors <lehors@us.ibm.com>,
Chet Ensign 
> <chet.ensign@oasis-open.org>, Martin P Pain/UK/IBM@IBMGB, Nick
> Crossley <ncrossley@us.ibm.com>, OASIS OSLC Core TC Discussion
List 
> <oslc-core@lists.oasis-open.org>, Paul Knight <paul.knight@oasis-
> open.org>, Robin Cover <robin@oasis-open.org>, Samuel Padgett
> <spadgett@us.ibm.com>, Sean Kennedy <seanpk@ca.ibm.com>
> Date:        30/04/2014 16:04 
> Subject:        [oslc-core] Re: OSLC specifications
at OASIS: 
> namespace processing and Linked Data server/client behaviors 
> Sent by:        <oslc-core@lists.oasis-open.org>
> 
> 
> 
> Note: I have tried to summarize this thread in the Core TC wiki [1]
> and what scenarios there are to we need to cover.  Feedback on
oslc-
> core@lists.oasis-open.org is welcome, especially if I missed any key
> scenarios or possible alternatives. 
> 
> [1]: https://wiki.oasis-open.org/oslc-core/VocabStableURINotes
> 
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> http://open-services.net
> 
> 
> 
> From:        Robin Cover <robin@oasis-open.org>
> To:        OASIS OSLC Core TC Discussion List
<oslc-core@lists.oasis-open.org>
> Cc:        Robin Cover <robin@oasis-open.org>,
Chet Ensign 
> <chet.ensign@oasis-open.org>, Paul Knight <paul.knight@oasis-
> open.org>, Arnaud Le Hors/Cupertino/IBM@IBMUS, Martin Pain 
> <martinpain@uk.ibm.com>, Nick Crossley/Irvine/IBM@IBMUS, Steve
K 
> Speicher/Raleigh/IBM@IBMUS, Sean Kennedy <seanpk@ca.ibm.com>,
Lin Ju
> <linju@ca.ibm.com>, Samuel Padgett/Durham/IBM@IBMUS 
> Date:        04/28/2014 10:59 AM 
> Subject:        OSLC specifications at OASIS:
namespace processing 
> and Linked Data server/client behaviors 
> 
> 
> 
> OSLC Core TC Members and related TC Officers [1] 
> 
> ** Summary: 
> 
> This message provides notification to members of the OSLC Core TC
> and related TCs that OASIS Staff has recently held internal 
> discussions about certain clarifications and changes in practice 
> with respect to server-client behaviors when delivering semantic web
> / linked data assets that are part of OASIS specifications.  We
are 
> collecting a list of specific OSLC-related requirements relating to
> transparent content negotiation, media/mime type entries in our 
> server configuration files, (possible) additional registration 
> requests to IANA, and advanced server configuration directives to
> support particular HTTP status codes in connection with server 
> responses that harmonize with HTTP request headers under content 
> negotiation.  Correspondingly, we intend to update certain details
> in the OASIS Naming Directives policy to accommodate community 
> expectations about semantic web / linked data in the DNS-HTTP 
> handling of HTTP-scheme URI references that are used to identify 
> namespace names and related named functions, properties, classes,
> behaviors, (etc) based upon (hash-terminal) namespace name 
> identifier strings. 
> 
> Please let us know directly (email to: robin@oasis-open.org ) or 
> speak with your TC members if you wish to be involved in discussions
> or providing input to OASIS Staff. 
> 
> **Immediate background:  
> 
> A question was raised within the PROMCODE TC about proper resolution
> of the namespace URI "http://promcode.org/ns/pm#",
which appears as 
> a base identifier several times in the March 26, 2014 version of the
> PEOMCODE specification uploaded to the Kavi repository [2].  The
> short answer to the question posed in JIRA ("What is the policy
for 
> namespaces at OASIS"?) is that when input specifications from
> external parties are contributed to OASIS for development of an 
> OASIS Work Product, we expect that the namespace names and 
> associated identifiers using the HTTP scheme will be changed in the
> OASIS specification to use the Internet domain "http://docs.oasis-open.org/
> " rather than some other domain not owned and managed by OASIS.
In 
> this case, the simple answer would be: 
> 
> http://docs.oasis-open.org/oslc-promcode/ns/[XXXX]
> 
> per the documented model for OASIS namespace name identifiers: 
> 
> http://docs.oasis-open.org/[tc-shortname]/ns/xxxx
> 
> See: http://docs.oasis-open.org/specGuidelines/ndr/
> namingDirectives.html#xml-namespaces 
> 
> However, since the PROMCODE TC is a member of the OSLC Member 
> Section, we understand that discussion may be required to better 
> understand architectural issues that include naming as it relates
to
> the several OASIS OSLC-related Work Products being developed in 
> individual OASIS TCs. 
> 
> ** Principal considerations about domains/namespaces from the OASIS
POV: 
> 
> 1. We understand that the technical work being transferred to OASIS
> from the historic OSLC Wiki (open-services.net) has been developed
> under well developed architectural principles that support Linked
> Data, including construction of identifiers for named properties and
> for expected server-client behaviors designed to deliver appropriate
> representations of resources based upon HTTP requests.  Some
of this
> is new for OASIS Staff, but we have had several discussions aimed
at
> strategies for updating OASIS practices, policies, and documentation
> to support Linked Data assets. 
> 
> 2. We understand that the transition of technical work from the OSLC
Wiki (
> open-services.net) to OASIS-owned web sites may take some time.  In
> most cases, where non-OASIS web sites support specifications brought
> to OASIS, the web sites themselves are transitioned to OASIS 
> ownership and management, ensuring that the brand as an asset is 
> associated with OASIS and that the resources are curated properly
(e.g., 
> amqp.org).  But in other cases, the non-OASIS web site may be
> maintained by the earlier owners, e.g., for marketing and 
> educational purposes (odata.org, mqtt.org) 
> 
> 3. OASIS has a policy-level commitment to governance and management
> of Work Product assets produced by OASIS Technical Committees, 
> including all approved work, which is published via the OASIS Library
( 
> http://docs.oasis-open.org/
).  Specifically: all OASIS TC outputs 
> are expected to be stored/maintained/published from OASIS-owned 
> Internet domains, including abstract assets like names within 
> (unbounded) namespaces.   The core assumptions are that OASIS
Work 
> Products deserve OASIS branding (by virtue of the associated 
> Internet domain) and require OASIS management for the purpose of 
> upholding the OASIS commitment to resource permanence and URI 
> persistence.   Individual TCc are allowed to control and manage
> names beneath an allocated TC "root" that incorporates the
tc-
> shortName (e.g., oslc-core, oslc-ccm, oslc-automation, oslc-promcode).
> 
> 4. As presented in the summary above (** Summary), we are prepared
> to discuss possible adjustments to namespace management for OASIS
> assets produced by the OASIS OSLC Member Section TCs, provided that
> the TCs come into agreement, and that the collective intent is to
> use the "docs.oasis-open" Internet domain.   Use of
the the 
> "docs.oasis-open" Internet domain will be important as a
means of 
> demonstrating that the OSLC specifications are indeed OASIS Work 
> Products.  Equally, use of "docs.oasis-open" will be
important 
> because we enforce a practice of explicit resolution/dereferencing
> of HTTP-scheme URIs that serve as namespace names and associated 
> identifiers.  Whether under content negotiation or otherwise,
we 
> expect that such identifiers to resolve under DNS/HTTP by the 
> delivery of an appropriate representation of a resource that -- like
> the core prose specification and the name itself -- is published via
> the OASIS Library, whether that resource is a human readable 
> "namespace document" or a schema file for a formal vocabulary
in any
> of several grammar/serialization options (e.g., .xml. .rdf, .ttl,
> .jsonld, .owl, .nq, .trig, .nt), or other representation as 
> described in the Work Product. 
> 
> I hope this communication about the baseline commitment of OASIS to
> support of the OSLC TCs' assets at the server/client interaction 
> level is useful  -- as we continue discussion about the specific
> requirements, as envisioned.  My assumption is that the OSLC
Core TC
> has the lead on matters of naming in OASIS OSLC specifications. 
> 
> 
> - Robin Cover 
>  OASIS, Director of Information Services 
> 
> ** Notes 
> 
> [1] OASIS OSLC (Member Section TC) TC Officers (04/25) 
> 
> Chairs: Please forward this message to your TC(s) as you may deem
relevant 
> 
> OASIS OSLC Lifecycle Integration Core (OSLC Core) TC 
> https://www.oasis-open.org/committees/oslc-core
> Arnaud Le Hors, lehors@us.ibm.com, Chair 
> 
> OASIS OSLC Lifecycle Integration for Automation (OSLC Automation)
TC 
> https://www.oasis-open.org/committees/oslc-automation
> Martin Pain, martinpain@uk.ibm.com, Chair 
> 
> OASIS OSLC Lifecycle Integration for Change and Configuration 
> Management (OSLC CCM) TC 
> https://www.oasis-open.org/committees/oslc-ccm
> Nick Crossley, ncrossley@us.ibm.com, Chair 
> Lin Ju, linju@ca.ibm.com, Secretary 
> Samuel Padgett, spadgett@us.ibm.com, Secretary 
> 
> OASIS OSLC Lifecycle Integration for Project Management of 
> Contracted Delivery (OSLC PROMCODE) TC 
> https://www.oasis-open.org/committees/oslc-promcode
> Mikio Aoyama, amikio@nanzan-u.ac.jp, Chair 
> 
> [2] PROMCODE initial specification 
> https://www.oasis-open.org/committees/download.php/52598/PROMCODE%
> 20Specification-140225L.pdf 
> Project Management of COntracted Delivery for software supply chain
> Interface Specification (Version 1) 
> October 22, 2013 (Original Version in Japanese) 
> March 26, 2014 (English Version Translated from the Original Version)
> 
> 4.2.2 Namespaces 
> In addition to the namespace URIs and namespace prefixes oslc, rdf,
> dcterms and foaf defined in the Core 
> Specification Version 2.0, PROMCODE defines the namespace URI of 
> http://promcode.org/ns/pm#
with a preferred 
> namespace prefix promcode_pm. 
> 
> 4.3 PROMCODE Resource Definitions (properties) 
> ScopeItem, with URI: http://promcode.org/ns/pm#ScopeItem
> WorkItem, with URI: http://promcode.org/ns/pm#WorkItem
> Artifact, with URI:http://promcode.org/ns/pm#Artifact
> Measurement, with URI: http://promcode.org/ns/pm#Measurement
> Issue, with URI: http://promcode.org/ns/pm#Issue
> Change, with URI: http://promcode.org/ns/pm#Change
> 
> 4.2.3 Resource Formats 
> For HTTP GET requests on all PROMCODE and OSLC Core defined resource
types, 
> (1) PROMCODE Providers MUST support RDF/XML representations 
> with media-type application/rdf+xml. PROMCODE Consumers MUST be 
> prepared to deal with any 
> valid RDF/XML document. 
> For HTTP POST/PUT requests on all PROMCODE and OSLC Core defined 
> resource types, 
> (2) PROMCODE Providers MAY support RDF/XML representations with 
> media-type application/rdf+xml. 
> PROMCODE Consumers MUST be prepared to deal with any valid RDF/XML
document. 
> For HTTP GET response formats for Query requests, 
> (3) PROMCODE Providers MUST support RDF/XML representations with 
> meda-type application/rdf+xml. 
> 
> See JIRA: https://tools.oasis-open.org/issues/browse/OSLCPROMCO-2
> "Description: The contributed PROMCODE spec is in a namespace
that 
> does not resolve, i.e.: http://promcode.org/ns/pm#
 What is the 
> policy for namespaces at OASIS, and what approach is the Core TC 
> (and others) taking? 
> 
> 
> -- 
> 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 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU