Annotation vocabulary shortnames and ID prefixes

[angus-lherrou]

Define a formal scheme for deriving unique shortnames and ID prefixes for MMIF vocabulary that is extensible to future LAPPS integration and user-defined ontologies

[angus-lherrou]

My current WIP implementation proposes the following scheme:

• A valid annotation @type is either a URI, a namespaced shortname, or a shortname on its own.
• If the @type is a URI, it is always valid.
• If the @type is a namespaced shortname, it is valid as long as the namespace is defined in the vocab package (currently only MMIF namespace is defined, in future probably LAPPS as well, in far future possibly support for user-defined namespaces/vocabularies). I'm proposing a colon-delimited syntax for namespaced shortnames, e.g. MMIF:Vocabulary or LAPPS:Segment.
• If the @type is a bare shortname, it is valid as long as it exists in the MMIF vocabulary (i.e., assumed to be in the MMIF namespace).
• The least-specific valid name for a type is considered the canonical representation for that type in the @type field. For example, the canonical representation of a MMIF BoundingBox is BoundingBox, the canonical representation of a LAPPS Segment is LAPPS:Segment, and the canonical representation of the "ArbitraryAnnotation" type defined at https://example.com/vocabulary/ArbitraryAnnotation is https://example.com/vocabulary/ArbitraryAnnotation. However, all valid names are accepted when processing @type from a MMIF file, and I could potentially add optional flags to enforce a minimum level of specificity in a given MMIF object (i.e. requiring an explicit namespace for MMIF shortnames, or requiring full URIs for everything).

@marcverhagen @keighrim I would love to hear your feedback on this proposal.

[angus-lherrou]

Now that we have @context in views, the need for full URIs for custom vocabularies is reduced, I think. I don't fully understand how JSON-LD works so it would be helpful if y'all could consider the above proposal and think about how we could adjust it based on the presence of @context, in addition to any other comments or suggestions you have.

[marcverhagen]

I think we should put this on the agenda for our next meeting. This needs more than a few emails back and forth.

[marcverhagen]

@angus-lherrou @keighrim

Well, maybe it does not need more than a few emails.

The context files in the view do change the story a bit. Each view has either the CLAMS or LAPPS file:

• https://mmif.clams.ai/0.1.0/context/vocab-clams.json
• https://mmif.clams.ai/0.1.0/context/vocab-lapps.json

These contexts make sure that in a CLAMS view something like TimeFrame will be expanded to http://mmif.clams.ai/0.1.0/vocab/TimeFrame (which is actually an error, I need to change "vocab" into "vocabulary").

So I think the story is a bit simpler than you had it

• If the @type is a URI it is valid.
• If it is not a URI it should/will be expanded into a URI given the context file

I don't think we have name-spaced names like LAPPS:NamedEntity so that would be an addition that does not seem to add anything since the context acts as the namespace.

Future third-party annotations should either use URI or use a user-defined context file.

There is the issue of requiring names to be in the vocabulary. That would simply be a check whether the URI exists. You did mention that if the @type is a URI then it is valid, so valid does not imply