I remember hearing talk about the need for a new database field to be added to Drupal core taxonomy.module's term_data table to stash the GUID/UUID/URI associated with a term. This was particularly relevant for sharing/importing/exporting taxonomies and using standard vocabularies. I suspect it also has relevance to RDF, but my comprehension is still a bit hazy on it.
OpenCalais calais.module adds a column 'guid' to the term_data table. I can't imagine that there would be any collision risks if other modules insert in this field as well for their own vocabularies.
I've reached a point in developing a module where I've realized I need this, too, and I don't know the best way to handle it. Should I check if the guid column already exists and re-use it? Or should I create a new column to store the guids for my own vocabularies? The latter seems silly.
Comments
Actually that guid field is getting removed.
In order to not sully up the term_data table with my data in the newer version of opencalais (coming out in the next day or so) I have removed the GUID field in term_data and the calais_term table now holds the GUID and a reference to the term_data row in the tdid field.
sully?
Are you just trying to be discrete and neat? Or do you think all taxonomy term URI GUIDs should be in related tables set up by each module that uses an external vocabulary?
Trying to be neat
I realize that many things would love to tie into taxonomy term data, but had second thoughts about actually storing that data WITH the rows in that table. I think it would best for modules to store data external to the actually taxonomy tables as it avoids future conflicts. It was also a bit messy in keeping it up to date, etc. This way makes a bit more sense to me conceptually.
I plan on releasing monday.
GUIDs
Frank: I understand your reasons. For me, the only thing I need is a GUID field, so I'd be creating that table and writing SQL JOINs just for this field.
I noticed that core's taxonomy_get_term function automatically loads all the fields in the term_data table, so without any special coding, the GUID is in reach using core functions. (It's still necessary to create space for this in taxonomy_form_term so that the GUID doesn't get dropped when a term is saved from the admin UI.) In D6, it's only possible to have other contrib modules rely on this data by putting it on term_data. In D7, this problem can be overcome with the new load hooks.
Do you think that there's any merit to putting a guid field on term_data?
I think there is merit.
I see your point and the ease of read, one less join, etc..
To clarify, is your idea that Drupal is generating GUIDs for each of their terms that could be exposed externally? or were you expecting contrib modules to make use of that field? If there are more than one contrib module that makes use of a GUID/URI for a Term, they might wind up overwriting each others data. That is up to module implementers, of course, but you never know what people may do. That was my main motivation for moving this data out into my tables.