oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Re: OSLC specifications at OASIS: namespace processing and Linked Data server/client behaviors
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: Steve K Speicher <sspeiche@us.ibm.com>
- Date: Thu, 1 May 2014 11:16:07 +0100
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]