Status: Discussion concluded, notes/options for historical purposes


OSLC has defined a number of vocabulary documents that follow Linked Data best practices for hosting on the web. There are a number of deployed vocabularies already and being used within shipped products. Since OSLC transitioned to OASIS, OASIS already set a set of established policies.

OASIS Policy Summary

To help with setting context for this discussion.

Namespace naming policy

example for OSLC-PROMCODE:

per the documented model for OASIS namespace name identifiers:

URI Persistence

Resource Permanence

URI Aliases

TCs must not use URI aliasing by any means, including, for example, unauthorized: (a) use of META-refresh elements, (b) preparing files with identical content under two different filenames within a given published instance, or (c) constructing URIs for canonical OASIS resources by using redirects supported by services on other Internet domains (e.g.,,,

OSLC Scenarios

Adding new terms to already established vocabs

Example is that in the OASIS OSLC-CCM TC, there is a need to add some new terms to the Change Management 2.0 vocabulary. The typical way to introduce these new terms is to add them into the existing Change Management vocabulary (not create a new vocabulary document).

Options when moving to a new namespace:

Since most OSLC tools today explicitly do not perform any inferencing, the value of any sameAs statement is dubious.

One option is to NOT move to a new namespace, instead put a policy in place to maintain the existing ones

Other solutions could be a mix, where one is the authority and the other redirects to it. For example, is what you'd find in the content of the vocabulary document but could redirect to it.

Deprecating terms

In some of the 2.0 specs, there was a need to no longer endorse the usage of a term. The approach to do so was to update its term_status to be deprecated.

New vocabularies

Either when a new TC is formed or when existing TC decides to create a new specification and vocabulary.

Cost of change to namespace

Today, the namespaces are built-in to many areas, including but not limited to the following:

  1. RDF data in triple stores in numerous databases for numerous tools scattered across the world - including some with no internet access
  2. Code that generates RDF data, in various languages, from numerous vendors, similarly scattered around the world
  3. Code that consumes RDF data, in various languages, from numerous vendors, similarly scattered around the world
  4. SPARQL queries and similar reports in files, or embedded in tools and code
  5. Web pages, such as tutorials, vocabulary pages, etc.
  6. Training courses, including recorded audio and video
  7. XSLT stylesheets and similar scripts to process or transform RDF data
  8. Exported RDF data in numerous file formats, including backups of databases, exported data for transfer between databases, etc.

To change the OSLC namespaces would require all the above to change. This would require many organizations to commit to the change, and massive effort to coordinate and implement the change. Several organizations would probably refuse to commit resources to such a change with no apparent benefit, leading to the dropping of support for OSLC. Even amongst those organizations that did commit to the change, the scope and distributed nature of the data, plus the requirement to provide ongoing support for previous releases of software, would require support for the older namespaces for a very long time - rendering the value of the change even more questionable.

Fundamentally, the cost of the change would be prohibitive, and the value seen by adopters and users minimal.

Summary of options






Move all OSLC 2.0 namespace items to

1. Follows OASIS established process 2. Everything is managed under 1 domain 3. less burden on OASIS staff

1. Existing impls break 2. Will lead to drop in support for OSLC from organizations unwilling to spend resources on a change 3. Will have to put in place and maintain "shims" at 4. Will have to continue to pay for separate domain and hosting 5. Will have to publish how to have vocabs co-exist, then update implementations

Cost of change prohibitive, even if IBM continues to donate domain and resources to maintain

Move only new vocab development items to, keeping pre-OASIS terms in separate namespace

1.Items aren't duplicated

1.Need to maintain a 2 vocabs 2. Impls need to look in 2 places 3. OASIS specs would leverage these vocab terms, and therefore need to make sure sticks around

IBM continues to donate domain and resources to maintain

Transfer domain ownership of to OASIS OSLC MS

1.Better control over domain not going away

1.additional effort on OASIS staff (small)

OASIS owns the domain, requests go to existing server infrastructure. IBM continues to donate server is still maintained by outside OASIS staff (currently IBM donated resource)

Keep vocab documents at*

1.Better control of domain and vocab 2.doesn't break existing impls

1.mix of non-OASIS terms (ArchMgmt, AssetMgmt, PerfMon)

Would probably require OASIS OSLC MS to take over ownership/control

Mirror and/or redirect vocab documents from to

1.Impls can be a bit more lax

1.Against the OASIS aliasing policy

OASIS owns the domain + management of /ns/*. Rest is same as previous.



VocabStableURINotes (last edited 2014-10-16 13:31:31 by sspeiche)