Deprecate and remove Vocabulary Management (Evoc)

yes, we never ended up cleaning that up... +1

plan sounds good. Maybe we could allow a few more weeks buffer time, like 6 weeks? or we could also ask anyone who needs more than 3 weeks to just say so... either way, +1!

Looks good. you might also want to mention that the removal of evoc will only affect the autocomplete of RDF UI, but people will still be able to add namespaces manually and set their mappings as long as they know what terms they want to use.

Related issue re future of RDF UI: #1130598: Make the RDF UI autocomplete more extensible.

Please also point to the service based approach wiki on gdo: Architecture of the centralized vocabulary republishing service

Thanks Lin for working on this. Uninstalling evoc works, and namespaces which were imported in evoc are preserved during the uninstallation.

+++ b/rdfx.install
@@ -71,9 +71,6 @@ function rdfx_schema() {
-    'unique keys' => array(
-      'gid_uri' => array('gid', 'uri'),
-    ),

any reason for removing this key? I guess we would need an update function as well. but don't we want to keep this unique key anyways?

+++ b/rdfx.module
@@ -391,3 +390,36 @@ function rdfx_features_api() {
+function rdfx_rdf_namespaces() {
+  // Starts with some additionnal common namespaces which core does not include.
+  $ns_mappings = array(
+    'owl'      => 'http://www.w3.org/2002/07/owl#',
+    'rdf'      => 'http://www.w3.org/1999/02/22-rdf-syntax-ns#',
+    'rss'      => 'http://purl.org/rss/1.0/',
+    // url() does not support empty fragment.
+    'site'     => url('ns', array('absolute' => TRUE)) . '#',
+  );
+
+  // Gets the custom namespaces stored in the database.
+  $query = db_select('rdfx_namespaces', 'n');
+  $query->fields('n', array('prefix', 'uri'));
+  $query->orderBy('n.prefix');
+  $namespaces = $query->execute()->fetchAllKeyed();
+  foreach ($namespaces as $prefix => $uri) {
+    $ns_mappings[$prefix] = $uri;
+  }
+
+  return $ns_mappings;
+}

This function assumes evoc has been uninstalled. If people apply this patch (or upgrade rdfx after this patch has been committed), and don't uninstall evoc, their namespaces will be messed up because it will include all the namespaces of the imported vocabularies, with conflicts etc. I think that until evoc is completely removed, we need to check in this function whether evoc is still enabled (if the rdfx_vocabulary_graphs table exists) and keep the old query if it's the case. This is the old code which joins with the evoc table

  $query = db_select('rdfx_vocabulary_graphs', 'g');
  $query->fields('n', array('prefix', 'uri'));
  $query->join('rdfx_namespaces', 'n', 'g.main_ns = n.nsid');

+++ b/rdfx.module
index 1bbc60f..0000000
--- a/rdfx.terms.inc
+++ /dev/null

maybe I'm confused, but I thought in the first patch/phase, we would provide the uninstall function for evoc, while leaving the evoc functionality in the module.

I thought this was the plan - let me know if I'm missing something:
7.x-2.0-alpha5 (next release): this is the last release of RDFx to include evoc. it also comes with uninstall function to cleanly remove evoc, if you don't use or need evoc, you might want to uninstall it.
7.x-2.0-alpha6: this release no longer includes evoc functionality. rdfx.install includes update function to force people to uninstall evoc if they haven't done so already. that's when the evoc code is being remove.

I just tried this patch and it doesn't work because _rdfx_extract_schema() is undefined. If you try to reinclude rdfx.terms.inc, then rdfx_rdf_namespaces() is defined twice. If you remove the old rdfx_rdf_namespaces(), then you still need to take care of returning empty autocomplete results when evoc is disabled... I feel like we're wasting too much time trying to fix some code that's going to be discarded in a few weeks. Lin, if you agree, let's just call 7.x-2.0-alpha4 the latest version including evoc, and let's commit something close to your first patch that will remove evoc and force people to uninstall its tables when they upgrade to alpha5. We're only in alpha anyways, so I don't think anyone will mind if we deprecate this functionality. I'd much rather spend time on more promising patches which will improve the module...

new suggested plan:
- post deprecation notice (#5 + #6)
- commit patch for evoc removal (most of the code is ready, uninstall function works well)
- roll a new release