Vocabulary Stable URIs and Evolution Notes (inactive, concluded)
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.
To help with setting context for this discussion.
Namespace naming policy
example for OSLC-PROMCODE:
per the documented model for OASIS namespace name identifiers:
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., , , ).
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
-
could involve transferring ownership of open-services.net to OASIS OSLC Member Section
-
involves minimal/zero impact on existing deployed solutions
Other solutions could be a mix, where one is the authority and the other redirects to it. For example, open-services.net is what you'd find in the content of the vocabulary document but docs.oasis-open.org could redirect to it.
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.
-
Option1: is to just leave open-services as-is and using existing process to update it there
-
Option2: is if OASIS OSLC Member Section takes ownership, it could just fall under that
-
Option3: if moving to new namespace, see above
Either when a new TC is formed or when existing TC decides to create a new specification and vocabulary.
-
Option1: picking the namespace has less restrictions and could follow regular OASIS naming policies.
-
Option2: transferring open-services.net as above, continue to use this as the base.
Today, the open-services.net namespaces are built-in to many areas, including but not limited to the following:
-
RDF data in triple stores in numerous databases for numerous tools scattered across the world - including some with no internet access
-
Code that generates RDF data, in various languages, from numerous vendors, similarly scattered around the world
-
Code that consumes RDF data, in various languages, from numerous vendors, similarly scattered around the world
-
SPARQL queries and similar reports in files, or embedded in tools and code
-
Web pages, such as tutorials, vocabulary pages, etc.
-
Training courses, including recorded audio and video
-
XSLT stylesheets and similar scripts to process or transform RDF data
-
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.
-
Option 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 vocabularies - as we already re-use other vocabularies too - LDP, RDF itself, etc. (But then again, W3C has stronger governance than open-services.net)
-
Option 2: Continue to use as the namespace domain. The management of the NS documents (but possibly not the wiki & community content) is transferred to OASIS for those NS transferred to OASIS TCs. 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. Optionally the registry of the domain open-services.net could transfer to OASIS MS.
-
Option 3: Move to new namespace. Possibly with redirects. Lots of things will break and need to change, including user experience. The cost of this change is prohibitive.
| Item | Pros | Cons | Notes |
| Move all OSLC 2.0 namespace items to docs.oasis-open.org | 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 open-services.net 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 open-services.net |
| Move only new vocab development items to docs.oasis-open.org, 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 open-services.net sticks around | IBM continues to donate domain and resources to maintain open-services.net |
| Transfer domain ownership of open-services.net 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 open-services.net server infrastructure. IBM continues to donate server is still maintained by outside OASIS staff (currently IBM donated resource) |
| Keep vocab documents at open-services.net/ns/* | 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 docs.oasis-open.org to open-services.net | 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. |
-
Option 2
-
Why 2? There needs to be something in place to manage namespace documents, it doesn't matter what the URL really is to a program...it is just an opaque string. OSLC has meaning, you can lookup the URLs to learn more about it. There is very little cost in owning a domain, in fact it makes sense for the OSLC MS to own/control this anyway (regardless of this discussion).
-
Changing the URL, seems like a non-starter...if adoption isn't great now, this is almost going to kill it for those who done it or started doing it. Going with a split approach seems like just extra work when you already have one.
-
This follows some of the vocab guidance, cool urls don't change. We want to be cool right?
-
