It'd be nice to have a "typed string" field type

[rosiel]

I'm thinking that along the lines of the "typed relation" (in which an entity may be related to an object as author, contributor, photographer, etc), we could probably used a "typed string" field. My first use case would be an "Identifier" field. Each Identifier would contain a string field and a taxonomy dropdown. The user would enter the identifier (e.g. 9784567890123) as a free-text string, and select a type (e.g. ISBN or ISSN or LCCN etc.) from the dropdown.

This could also be used for notes with types (coming from MODS), and probably others.

[seth-shaw-unlv]

I think we have two separate use-cases here.

1. Creating a data-entry form (Field Widget) to control how a string is constructed; e.g. the widget concatenates the value from the dropdown ('doi:', 'isbn:', etc.) and the textbox ('9784567890123') into a single string value 'doi:9784567890123' and stores that for the field value. This is relatively simple to implement.
2. Creating an actual typed Field Type storing the 'type' and the 'value' as two distinct field values, as done for the typed relation field type. I've done this before for the ArchivesSpace-Drupal integration project which could be pulled out as a separate module. This is useful for keeping the number of fields attached to a content type limited (one field for typed notes rather than 20+ representing each different type of note). HOWEVER, this is problematic for establishing search relevancy. You wouldn't be able to boost, diminish, or exclude any particular note type. Well, perhaps you could through some extensive customization of the Search API, but I wouldn't want to try. Also, they would all have the same RDF predicate unless we updated hook_jsonld_alter_normalized_array() again. The most Drupal-ly way is to simply create a field for each note type you want.

[whikloj]

Was this ticker resolved by the controlled_access_term module or is this still a desired feature?

[seth-shaw-unlv]

No. This has not be implemented in Islandora 8 or Controlled Access Terms.

As I mentioned, I do have a solution in ArchivesSpace-Drupal, but I don't know that people will want to install that module just for the typed string field. It could be pulled out as a separate module if folks really want it despite the complications I mentioned in my last comment.

[rosiel]

I'm more concerned about management and interfaces. I mean, I understand that with some interstitial layers (including conditionals, and maybe some widgets), we might be able to make something useable. But is it more "Drupally" to make this many separate fields?

• ISNI
• VIAF
• JST
• DIA
• DOI
• ISSN
• eISSN
• lISSN
• ISBN
• ArXiv ID
• bibcode
• ean13
• fundref id
• handle
• infouri
• LSID
• NIHMSID
• NII
• OCI
• OpenID
• ORCID
• PMCID
• PMID
• PII
• PURL
• Thomson Reuters Researcher ID
• SICI
• GRID
• Crossref ID
• Locally controlled ID schemes for people, objects, organizations
• and any other schema we can find

(I'm not just brainstorming! I'm trying to implement the Datacite Spec, and most of these are present there.)

This is too many fields to present in a form to a user, and not fun to configure in displays either.

[seth-shaw-unlv]

@rosiel for identifiers I would probably use the first solution I described: building a "typed identifier" widget and formatter (for data entry and display, respectively) but storing the value as a concatenated string rather than the second option of creating a new field type (or the implied third option of creating a whole bunch of fields).

[noahwsmith]

Putting in my support for this feature as an option to facilitate multilingual metadata tagging.

[kspurgin]

I think part of this got discussed/referenced in the Islandora8 Slack channel and then moved to the new #multilingual slack channel, but I wanted to highlight/capture a few things here.

• I'm wary of something like this being used for multilingual metadata tagging. I think the overall consensus on the Slack channel was maybe that this field type is not really for that. Handling multilingual metadata with this sort of field type with type=English and type=French seems to conflate multiple issues/problems.

• I'm in favor of exploring this field type and the best way to make it happen. I have questions about the implications of storing the whole thing as a string for: indexing, interoperability as linked data, and reuse/mapping outside Islandora such as via OAI-PMH or any kind of "generate" citation functionality, etc.

  • INDEXING: would the type/label end up as part of the indexed value? Depending on how search is configured, that could be a problem? Especially for identifiers which folks often want to index as strings (literal, full match) rather than text (fuzzy, natural language parsing, etc)
  • INTEROPERABILITY/REUSE - given example of typed identifier field with type = ISBN, would this return a string value like "isbn:9780498570" and is that workable for known linked data/data harvesting use cases if we have them? Could a citation generator grab only the ISBN or ISSN as appropriate? etc.

• A metadata administrator-level user needs to easily be able to add new types for a given field. When I think of how I'd expect to do this in a system with taxonomies (including taxonomies for other system behavior), I imagine creating an "Identifier type" taxonomy for use with my Typed Identifier field (instance of Typed String field type), or a "Note type" taxonomy for use with my Typed Note field (another instance of Typed String field).

• A metadata administrator-level user needs to easily manage the URI predicate(s) associated with each type. Ideally the predicate(s) for the type are used to generate the RDF for a statement of "object - predicate - stringliteral"

• The field type should support empty or blank type for cases where it's just a general note or some random identifier. (Under the hood this could be "Typed String field named Note with default type = note"). Otherwise you end up having to create a separate text field for the values without a known specific type, which complicates or breaks indexing/searching on "notes", etc.

[noahwsmith]

So how do we move this forward? I personally believe this is a decision that should be made by Islandora end-users (metadata folks, to over-generalize) and that the software folks should implement that spec decision. If folks agree with that approach, can this go to ICC and/or the Metadata Interest Group for a decision? Then an issue could be written up, and the work could be done in an upcoming sprint. My personal belief is that Islandora will be better if this decision is made by non-developers, because the correct solution here is what represents the data most correctly, not what technical solution is most appealing.

CC @manez @dannylamb @dara2

[rosiel]

Kristina's comment, along with my original issue description, cover my interpretation of the discussions, needs, and decisions expressed in the MIG [1], [2] and if I recall correctly, the User Call. As for a ticket... how about this one right here? It highlights several use cases, describes reasons for wanting them, and outlines a technical solution that nobody has said is not possible. If there's a feeling that it's important, I can bring the issue of not being able to alter the indexing relevancy by the value of 'type' to the next MIG meeting (IMO it is minor, nonetheless, it is useful to know the kinds of limitations/drawbacks that may not be otherwise obvious from a particular implementation).

(BTW, the MIG does have a document coming up requesting changes to Defaults with regard to technical metadata.)

[noahwsmith]

Then I'll rephrase my question with Rosie's last comment as the context: how do we move this from talk to action, if this has been blessed as a thing that Islandora should do/support?

Does this go to ICC for placement onto our roadmap, and/or on to the i8 Committers for implementation planning and execution? Or do we just wait until this organically is implemented as part of a specific institution's work, and just take what we can get because they're doing it as volunteers, even if it doesn't match the spec that Rosie and Kristina have laid out?