Re: OSLC specifications at OASIS: namespace processing and Linked Data server/client behaviors

[Steve K Speicher <sspeiche@us.ibm.com>]

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