Add a convention ID base field to assets and logs (simple string)

Some questions that come to mind right away:

• Should this be a single or multi value field? (I tend to think multi value since you could have a convention for the naming of a log and a separate one for the way it uses quantities.)
• Should the convention be a taxonomy or some other kind of entity reference so additional data about the convention has a canonical place to be stored?
• Should there be any restrictions on the naming of convention machine name? e.g. should it only allow characters that are easy to represent in urls to make future external "convention registries" simpler and more user friendly?

Should this be a single or multi value field? (I tend to think multi value since you could have a convention for the naming of a log and a separate one for the way it uses quantities.)

Yea I think it should be multi-value too. I mentioned that in the summary:

This field should allow multiple values. There could be cases where a one record is adhering to more than one convention at the same time (assuming they do not conflict).

Should the convention be a taxonomy or some other kind of entity reference so additional data about the convention has a canonical place to be stored?

@Farmer-Ed proposed something similar in the forum topic:

Could that field reference some sort of entity that stores the convention and/or a link to its repository?

https://farmos.discourse.group/t/documenting-conventions/1263/4

I'm inclined to start simple with this. It's possible to expand from a simple string to some kind of more complex entity in the future, but it isn't possible to go in the other direction. (It would be a breaking API change either way, of course... but maybe a string is our first MVP, and we see if something more elaborate is warranted for 3.x.)

A simple string field keeps the barrier to experimentation very low. It wouldn't require creating additional entities before you could start tagging conventions. I think we'll learn a lot about how this gets used once it's in the wild.

I'm hoping that the proposed structure and namespacing of the convention IDs themselves will serve as a simple way to find more info about the convention - and perhaps we can give this some more thought too (a convention itself, as @Farmer-Ed said). I'm also envisioning a "directory of conventions" hosted on farmOS.org... perhaps starting with just the core conventions, but then allowing others to add links to other contrib repos as well over time.

Should there be any restrictions on the naming of convention machine name? e.g. should it only allow characters that are easy to represent in urls to make future external "convention registries" simpler and more user friendly?

Great question! I don't think farmOS should make this decision, though. I think it can be a community convention we standardize on as the "convention registry" (great name for it!) comes together. I want to allow for experimentation within a single instance as much as possible.

I'm supportive of this but also wonder if a simple string field by itself is sufficient. The biggest thing that comes to mind: what happens when a record is modified and no longer conforms to a convention?

I believe I saw this mentioned somewhere, but these conventions should likely come with validation logic to ensure the value of the convention is indeed "correct".

It would also be nice if conventions could provide a "label" and "description" as well (similar to #2, perhaps each convention could have an info/help page, or at least link to the convention registry). This could be displayed in the UI and help explain to the user more context about the record and perhaps provide a warning that editing the record may break/remove it from the current conventions.

This is currently an issue with the Coffee Shop integration, if users modify records in farmOS they may no longer be compatible with Coffee Shop. I largely believe they should be able to modify these records as they please, but an info/warning message may help users edit records so that they still conform to a convention.

With that in mind.... perhaps conventions could be provided via a plugin system. These could include machine ID (is version included in machine ID?), label, description, and possibly even a helper method for providing validation logic. I like the idea that conventions need to intentionally be provided via a module.

@paul121 and I had some good back and forth in chat about this, so I'll try to respond to his comment above by reiterating some of the points I made there (hopefully more cohesively 😄)...

First and foremost, I think it's important to acknowledge that "validation" of conventions is a MUCH bigger topic, and I expect there to be a lot of back and forth on various mechanisms and requirements for that alone. I think we should keep that separate from this (as much as possible). It is a natural follow-up and I'm excited to see what bubbles up in the process. I know that some work has already started outside of farmOS, at least experimentally, using JSON Schemas and the farmOS API (not in PHP), by Octavio and Jamie and Greg in SurveyStack and the Farmer's Coffee Shop project. I see that work as being on a convergent path with this.

I think there is value in taking this first step of being able to declare conventions on records before being able to validate them. As a concrete example, I am working on this right now and decided to postpone it pending the addition of this convention field: ✨ Quick Form: Pasture Condition Score Sheet Postponed

But setting all that aside, let's assume hypothetically that we had the ability to validate conventions right now...

what happens when a record is modified and no longer conforms to a convention?

It would be great if this could be avoided, but in practice I'm skeptical that it will ever be 100% possible to avoid mismatches (eg: a record that declares its convention, but is not actually valid). There are just too many ways for things to "go wrong" in this regard. If the expectation is that farmOS data is "perfect" and that it always abides by the convention it says it does, then downstream code will inevitably break when that turns out to be wrong. The fact that people can self-host farmOS and potentially run raw database queries themselves (against all our efforts to dissuade them!) is enough for me to conclude that I would never trust the data, personally, regardless of how great and perfect my code is (HA!). :-)

I think it is better for external consumers of the data to perform validation themselves, and for us to work on making THAT process easier... in addition to any internal validation mechanisms that we do add in the future.

"Trust, but verify"

To be clear, I *do* want to see mechanisms for validating conventions, both internally and externally to farmOS. There are a ton of exciting ideas for this. And I think those can be added after this initial convention field, and key off of it.

We should be very clear that the convention field is a declaration of intention, but NOT a confirmation of valid data in and of itself.

If we agree to all of that (big if perhaps), then I think we can set aside the topic of "validation" and focus on the other big question that @paul121, @symbioquine, and @Farmer-Ed all raised:

I'm supportive of this but also wonder if a simple string field by itself is sufficient.

If we aren't considering validation as part of this, then the main reasons I've heard for creating an object of some kind (whether that be a taxonomy term, a config entity, a plugin, or something else), is so that additional meta data can be stored alongside these "convention objects", and this convention field would be a reference to those objects.

My counter-question to that is: what is the benefit of each individual farmOS instance storing/replicating this meta information, as opposed to just putting that information in a convention document markdown file, which can then be (optionally) aggregated into a central "convention registry" on farmOS.org?

And: what new barriers does requiring an object/config/plugin add? I'm proposing that we make this convention field hidden initially, but what if we didn't hide it? What if we let users experiment with it themselves? It feels like simple strings (that represent the "convention ID") allow for a lot of power! Is there a big risk in allowing this?

I'd like to advocate for a relatively flat structure that indicates the three points of reference I mentioned in this long-ago issue over on the OpenTEAM Gitlab:

It should have the following identifiers:

1. The entity and bundle it constrains (eg, "log--input")
2. The convention name or id
3. The convention version number

The first identifier I think would be specified implicitly by the type of the asset or log itself, but I feel like it will be crucial to have both a unique namespace, eg log--input--usda_organic, as well as a semantic version number for the convention itself. So, when represented as JSON, something similar to what you see in a composer.json or package.json file:

{
  "type": "log--input",
  "convention": {
    "log--input--usda_organic": "^2.1.0"
  }
}

In other words, a flattened dependency graph, which is ultimately what I think these conventions represent.

Apart from that, I totally agree with @m.stenta that there doesn't need to be anything in the convention field itself that implements any form of validation or enforcement, but I think it will be critical that it can at least provide an identifier that can be used in the future to reference specific means of validating them that is consistent.

Thanks for raising those ideas again @jgaehring!

I'm imagining this new convention field as a simple string/text field. The content of the field could technically be any string at all (allowing end users to make up their own IDs if they really wanted to), but the intention is that it would contain a "convention ID" string as described here: https://farmos.discourse.group/t/documenting-conventions/1263/2

Imagine adding a new convention_id field to assets/logs which lets you reference the convention ID (eg: farmOS:soil-test:1.0) that you intended to follow.

(Only difference is that I'm proposing the field be named convention instead of convention_id for brevity/elegance.)

Apart from what those IDs look like (a separate question IMO and really a convention in itself!) do you see any issues with this approach?

It would be a very simple first step to allow a simple "convention ID string" to be saved on each record as way of saying "this record intends to follow this convention".

Everything else (schema definitions, validation, documentation, etc) can all be keyed off of these IDs down the line... and all of that can be added incrementally in the future, building on this first step.

As a real world example, to illustrate my motivation for starting small, take a look at this feature request: ✨ Quick Form: Pasture Condition Score Sheet Postponed

The goal of that is to:

1. Document (as a convention specification) how to create a "Pasture condition score" observation log in farmOS.
2. Provide a "Pasture condition score" quick form that creates a log to that spec.

I basically want to be able to say, "if you want to create a pasture condition score observation in farmOS, follow this specification." The intended audience is both developers AS WELL AS normal users who want to create a log manually that is comparable to others. Here is what the draft of the convention specification document looks like: https://github.com/farmOS/farm_nrcs/commit/9de9f697ffb9dbacc20a67b73d8b7...

Then, I basically followed that specification myself (as a developer) when I built the quick form. This quick form is complete and ready for next steps / final review - but I would love to be able to save the convention ID (NRCS:pasture-condition-score:1.0) to the log that gets created by it, to explicitly state that "this log intends to follow the NRCS:pasture-condition-score:1.0 convention".

We have a number of other quick forms in the pipe that have similar requirements, so I'm excited to nail this first step down! I feel that this approach offers a lot of flexibility for next steps without pigeon-holing or over-engineering.

What do you think? Does that all make sense?

I made a 2.x-convention-field branch to demonstrate exactly what I'm proposing. It's about as simple as it gets (most of it is documentation). Tests are passing and it's ready to go (feel free to try it out locally)! :-)

See the diff for specific changes, along with additions to the farmOS.org docs that attempt to summarize the purpose/intent: https://git.drupalcode.org/issue/farm-3336224/-/commit/9414110e84489520c...

If we want to take a more complicated approach, maybe we close this as "won't fix" and experiment in contrib first? I figure either way this was an easy first approach to propose for consideration, and easy enough to sketch up.

Here is a screenshot of logs filtered by convention ID in the API → (via the following endpoint+filter: /api/log/observation?filter[convention]=NRCS:pasture-condition-score:1.0).

And just for giggles I made the field visible in my local instance. Helps to see what this looks like. Here is an example pasture condition score log:

• screenshot of log edit screen →
• screenshot of log view screen →

I do agree:

1. Validation doesn't need to be a requirement for what you are describing
2. A registry of conventions is valuable & we shouldn't replicate all of that metadata in farmOS. Only suggest to have a label, description and link to registry available if/when these are added to UI, because that probably shouldn't be parsed from a remote markdown on the fly.
3. A flexible string is nice, but some thought to structure seems smart.. Versioning seems useful and is interesting to think about it like dependencies. In particular it would be amazing if you could use a semantic version specifier in a query.... but that is probably beyond JSON:API features...

But I still have mixed feelings regarding what real value this brings and the expectations of & how this convention field would be used. I'm curious to hear more about the immediate use-cases that would be consuming this convention field & why exactly it is needed. Presumably they would be consuming logs via JSON:API. I do see how a convention field makes it convenient to filter logs implementing the convention:

/api/log/observation?filter[convention]=NRCS:pasture-condition-score:1.0

However, wouldn't this mean that this use-case (or even the convention itself?) is dependent on the convention field being populated on the logs in question? I believe that the *default* way we recommend querying farmOS for data that matches a convention should indeed return ALL data that matches a convention, regardless if they have the convention field populated.

Once we introduce a convention field it seems like that will then become the shortcut for querying relevant data conforming to a convention and is prone to failure. As it stands it's not clear to me what other use-cases exist for this simple string field. If this is the primary use-case that is OK, but it seems like it may be a short-term solution for some specific use-cases.

but I think it will be critical that it can at least provide an identifier that can be used in the future to reference specific means of validating them that is consistent.

This is the one other unique use-case that does stand out but tbh still isn't clear to me. "I created this log and intend for it to conform to this convention".... that is nice, but couldn't this also be confirmed by working in the other direction, applying a validation/query to logs to see what matches a convention? Am I missing something that is so important about storing this actual "intention" of conforming to a convention?

I mentioned this in chat with @mstenta, this really brings back the ideas about capturing the "intended purpose" and/or the "created by" metadata when a log/asset comes from a third party. It then becomes possible for the third party to query which data was "created by" their integration, or perhaps query data for an "intended purpose". (FWIW I may not be doing this justice, I do not think these ideas were originally my own & I'm not sure if these ideas were ever captured in forum/issue queues... :D)

I could see an argument for this convention field being really quite similar to this idea, in which case this may just be a matter of semantics & what we call the field.... But still I think think these "intended purposes" use-cases are unique from capturing "intended convention" in a convention field. Largely because the "intended purpose" is not a well defined convention, the "intended purpose" only exists once the data/thing is declared as being an "intended purpose". The convention is distinct because it is well defined and has many other "rules" in place that define if some data conform to the convention, not simply when a convention field says so. I worry that the convention field will be treated as a source of truth.

We should be very clear that the convention field is a declaration of intention, but NOT a confirmation of valid data in and of itself.

I think it is better for external consumers of the data to perform validation themselves, and for us to work on making THAT process easier...

For these and other reasons already stated would it be more productive to work in reverse... what if a documented convention came with the JSON:API filters to use & begin a filter down to relevant logs? It could be a very long query. And may even require subsequent steps/processing. But out of the box this would prevent two issues I'm worried about: 1) data that does not have a populated convention and 2) modified data that no longer conforms to its convention field. I know there are already thoughts & efforts to include more robust 3rd party schema validation as well, which is great, a JSON:API filter is just how I would first approach this for a convention implemented in farmOS.

We have a number of other quick forms in the pipe that have similar requirements

I think it's worth noting that logs and assets created via quick forms will have their quick field populated with the ID of the relevant quick form. And this field can already be filtered via the API. Thus, it could be quite possible for a convention to even document "all logs created from the "xyz" quick form should conform to this convention" and "use this query to get logs created by this quick form". Is this a potential solution for the immediate use-cases?

All great points and questions to raise @paul121! We're getting to the core question... (and part of that is asking whether or not it makes sense to do anything in core right now - if not, I would be fine with closing this specific issue as "won't fix", this discussion has been valuable either way IMO!)

Once we introduce a convention field it seems like that will then become the shortcut for querying relevant data conforming to a convention and is prone to failure.

It would be a shortcut, yes - and there may be value in that alone. There is another important benefit that I'll get to in a moment...

"Prone to failure" depends on expectations of the data consumer (sounds like a rehash of the validation question). If there is an expectation that it indicates validity, I agree. But if we make it clear that validation is separate, then "failure" would only be due to a misunderstanding by the consumer. I think best practice should always be to "trust but verify" data pulled from the API. To reiterate my feelings from above:

in practice I'm skeptical that it will ever be 100% possible to avoid mismatches (eg: a record that declares its convention, but is not actually valid).

So maybe the question this all boils down to in the short-term is: is there value in storing the "intended convention" on assets/logs, and being able to "query by intended convention ID" via the API?

Currently, with SurveyStack and the Coffee Shop, the flow (as I understand it) is: SurveyStack surveys encode an "implicit" convention by pushing data into farmOS instances in standardized ways. The CoffeeShop then queries data from each farmOS instance, using JSON:API filters where possible, and then performs its own validation to filter out records that don't match those conventions. The reason it does this second round of filtering is because of the situation described above (which will always be possible):

if users modify records in farmOS they may no longer be compatible with Coffee Shop

Let's take a step back for a moment.

There are multiple "problems to solve" in the world of farmOS conventions and aggregated data. Off the top of my head, these are the ones I can think of (not comprehensive), and the rough order in which I can imagine implementing them (because they build on one another):

1. Indicating the "intended convention" alongside each asset/log (*This is the focus of the current discussion IMO, and whether or not it is necessary and/or provides value.)
2. Validating that data matches a convention (Let's start a separate thread on this in the forum to start thinking through all of that, because it's a BIG topic, and not trivial to implement.)
3. Automatically detecting/tagging records with convention IDs that they match (depends on having validation logic in place)
4. Providing UI/UX in farmOS to notify the user if their edits to a record make it invalid (also depends on validation logic)
5. Pulling data from instances in an efficient manner

If we move forward with this issue (aka #1 above: add a convention field to assets/logs), we would take a big step forward on #5 (pulling data efficiently) at the same time, because it would be possible to very simply say "give me all the records that intended to use this convention".

I can imagine this would benefit use-cases like the Coffee Shop quite a bit, by reducing the amount of data that needs to be sent over the network as well as the amount of validation that needs to occur after that. Granted, the Coffee Shop case specifically would require additional work to take advantage of this right now (because a lot of data has been pushed already without declaring a convention, but that is solvable if we really wanted to). Point #3 above would improve #5 even further, by automatically tagging records with conventions that match. That can't happen until #2 (validation logic) is available, though. But I'm confident that will come together soon as well. Per my original statement in the issue description:

some work has already started outside of farmOS, at least experimentally, using JSON Schemas and the farmOS API (not in PHP), by Octavio and Jamie and Greg in SurveyStack and the Farmer's Coffee Shop project. I see that work as being on a convergent path with this.

Notably, and I think a very strong argument for #1 (this proposal) is: #4 (notifying the user if their edits to a record makes it invalid) is not possible unless we have a way to store the "intended convention" on each record. There's nothing to compare against if we don't know what the original intention was.

A few brief responses to other points:

Only suggest to have a label, description and link to registry available if/when these are added to UI, because that probably shouldn't be parsed from a remote markdown on the fly.

Agreed - this is still something to figure out! But it won't be necessary until we actually need to display convention information in the farmOS UI (eg: #4 above). I expect we'll have a lot more discussions around the "convention registry" ideas before we get to that point, and maybe we will find it unnecessary to store anything in farmOS. In other words, I think we can punt on figuring this out until some of the broader pieces start to develop.

some thought to structure seems smart.. Versioning seems useful and is interesting to think about it like dependencies. In particular it would be amazing if you could use a semantic version specifier in a query.... but that is probably beyond JSON:API features...

Yea I love the idea of querying using semantic version constraints! But I agree it might be outside the scope of JSON:API. Worth noting, it would be possible to get pretty close with what I'm proposing. JSON:API supports filtering via a contains operator ( see docs → ). So if you wanted to get all logs that referenced version 1.0 AND 1.1 of the NRCS:pasture-condition-score convention, you could ask for all that contain NRCS:pasture-condition-score, and then do a secondary filtering outside of JSON:API to get only the specific versions you want.

I believe that the *default* way we recommend querying farmOS for data that matches a convention should indeed return ALL data that matches a convention, regardless if they have the convention field populated.

I think there's value in offering multiple options. One way is to query the API with a big set of JSON:API filters. Another is to use a single convention filter. The former is the "cautious" approach, when there isn't much control over the data input, and you want to make sure you don't miss anything. That's not always necessary. The latter is much more efficient when you do have more control, and there is value in that. And if/when #3 above is implemented (automatically tagging records) then there's less chance of missing things so it works even in low-control situations.

This is the one other unique use-case that does stand out but tbh still isn't clear to me. "I created this log and intend for it to conform to this convention".... that is nice, but couldn't this also be confirmed by working in the other direction, applying a validation/query to logs to see what matches a convention? Am I missing something that is so important about storing this actual "intention" of conforming to a convention?

Notifying the user that their edits will break the intended convention (#4 above) is impossible without knowing what the intended convention was.

For these and other reasons already stated would it be more productive to work in reverse... what if a documented convention came with the JSON:API filters to use & begin a filter down to relevant logs? It could be a very long query. And may even require subsequent steps/processing.

I think we should do both! I think the "working backwards" approach absolutely provides additional value. And I think it is MASSIVELY more complex. So in my opinion there is value in doing both, for the reasons described above. Most importantly because it enables #4 (notifying the user that an edit will invalidate their intended convention) in the future, and it gives us a big leg up on #5 (efficient API queries for high-control scenarios) right now.

I think it's worth noting that logs and assets created via quick forms will have their quick field populated with the ID of the relevant quick form. And this field can already be filtered via the API.

This is true of records created by quick forms. It is not currently true of records created via the API (eg: SurveyStack records that the Coffee Shop wants to find).

Also, the quick field is more along the lines of the "created by" metadata (which is also useful and perhaps we should give thought to generalizing that for broader use beyong just quick forms). "Intended convention" has a more explicit purpose.

(eg: farmOS:soil-test:1.0)

That's perfect. But I have to ask: Are we just reinventing RDF?

;-P

I agree with what Paul just said. Octavio could second, but imagine receiving a log and asking "what convention is this" with no reference... that's a LOT of validation queries. Sometimes you will have to do this, but it's time consuming.

Better to know what you SHOULD validate against by storing that in the log... then if you want to go on a wild goose chase after that, you can if needed.

I also think if we're being honest and thinking long term, the real value of conventions is in validation. As a user, do I want flexibility? Yes! But as a user do I want to know that 95% of what I need works out of the box, in a way appropriate to me, because as a farmer I don't want to also be a full time software designer but I do want to use best practices so we're not constantly reinventing the wheel? Double yes!

That requires real conventions that validate data structures and enforce (soft or hard) inside farmOS or whatever programs are being used.

Lastly... and I brought this up with Mike on the phone but I'll post here... this idea in OpenTEAM of an Ag Data Wallet is really just the registry of schemas (or little conventions, like "a tillage log"), and the ability to package schemas together with written descriptions into a convention (or big conventions, like "OpenTEAM follows all these rules together")). But in order to have this widely used, and to avoid forking unless necessary, I think we need to think up front about how a registry is assembled, where and how it's contributed to, and how to default to referencing existing schemas rather than copying them which would cause a mess.

I know that last part is a big ask and easier to talk about against an example, and we need to build out a convention for the coffee shop, so hoping to bring something to the table rather than just complaining there also :)

I wrote a long post... it got deleted... grf.

short... validation is the long term main benefit. Users want things to work first and not have to reinvent best practice wheels, and have flexibility second (important... but second). validation gets things to work and nicely. the structure should enable validation from day 1, and follow naming and structural norms in other places (like json schema or npm or whatever).

Thank you @jgaehring for reminding me!

Are we just reinventing RDF?

I would say that we're aiming towards RDF!

That is another potential use-case that might leverage this "intended convention" info on records. I'm imagining using that as a way of offering RDF serialization(s) of records. That's a topic for another time... as is the "format" of these IDs IMO.

But the bottom line is that we're talking about storage of this new piece of information right now (the "intended convention"). All the various ways that this info is used are next steps.

Just want to capture this question that came up in a Slack chat with Octavio, because it's relevant to this discussion:

Octavio: Let's say that convention involves 10 entities. Will all of them be tagged with the convention, or only the topmost one, (the log in this case)?
mstenta: Ah this is a really good and important question
mstenta: So... in the specific feature request linked above... I only proposed adding it to assets and logs, and not to quantities
mstenta: But there could be an argument for adding it to quantities as well
mstenta: My thought was that quantities are always associated with ONE log (and therefore in someways they are "part" of the log)
mstenta: So I wasn't sure if it was necessary
mstenta: But... to answer your broader question: yes! For example if a convention includes both assets and logs, then I think you would tag the convention ID on all assets/logs involved
mstenta: For example, perhaps there is a very generic "Planting" convention, that describes how to record the lifecycle of a plant
mstenta: This would involve both the plant asset, as well as potentially seeding logs, etc
Octavio: Ok, I believe we can avoid adding it to the other entities.
mstenta: I tend to think so to... at least initially. Maybe we'll find that it becomes helpful later.

We talked a bit more about this feature request on the farmOS dev call today. It seems that there is general agreement (on our call and in this thread) on the broad points:

• We need to be able to indicate the "intended convention" of assets/logs.
• We need to be able to validate those conventions, in a number of different contexts.
• We need a registry (centralized and/or federated) of conventions.

Where there is still disagreement is in the specific implementations.

And just to be clear: this specific thread is focused ONLY on the first one, and the specific approach I proposed for that: adding a convention field to assets/logs for indicating "intended convention". I am playing devil's advocate for the "simple string" side, which is to say: perhaps we only need to store the "convention ID" (a simple string), whatever that is (could be a URL!), and that can be used to look up everything else via a registry later (when that becomes available), including schemas for use in validation. I think there is value (even minimal) in adding this field right now, since it is a trivial change, so that it can begin being populated, even if it doesn't get used until the other stuff described above gets built out.

The counter-argument against the "simple string" approach is (as I see it): it does not provide a way to include additional metadata about the convention.

The counter-counter-argument in my mind is: all that stuff can be looked up in the future via the registry. And even if we decide to make this convention field more complicated in the future (when we have a better sense of how it will be used and what's needed), we can pretty easily migrate from a simple string to an object reference via update hooks.

Hope that summarizes the current state well enough. :-)

So to boil it down to the simplest question: Is there value in merging this change now so that "intended convention" can start being populated? Or should we wait until some of the bigger pieces are coming together (acknowledging that that may not happen soon) and figure it out then?

yes! yes yes! yes please yes!

I feel like I'd need to talk it out to get to the exact detail of what that object is, but happy to do it. I think we can do a good job really, and already what's been written here is really smart starting point.

But yes, my vote is yes on that. We can use this really quickly in the coffee shop.

I spoke with @gbathree offline and clarified that his vote is in favor of this field being a reference to a more complex object that includes metadata.

I will go ahead and close this as "Won't fix". I've updated the title+description to make it clear that the focus of this thread was the "simple string convention ID" approach. We can open a fresh issue specifically for the future implementation when we have a better idea of what that will look like.

Thanks for the input everybody! We got a lot of good trains of thought started here. :-)

Update: We came up with a potential approach on today's dev call. I opened two feature requests, which independently are simple (but powerful), and combined would meet the current needs for convention referencing, I think:

#3390486: Add an Ontology URL field to all taxonomy terms →

#3390489: Add a Convention taxonomy reference field to Assets and Logs →