This literally came to me in a dream: Does it make sense to think of book lexicons like video file formats?
For example, the .mkv format is “a container format that can hold an unlimited number of video, audio, picture, or subtitle tracks in one file.” The stuff can be of different types (e.g. encoded with different video and audio codecs).
In a similar manner, would it make sense to have a top level lexicon that functions as a container that you put other stuff in? Like a minimal root level lexicon with other lexicons defined that go into it. The idea being that instead of trying to accommodate everything from the start it would provide a way to make ongoing adjustments and expansions.
(I know one of the guidelines with lexicons is to not change them once they are published, and the idea of adding child lexicons runs foul of that. But, it feels like having a type of expansion built in would be a proper indicator that downstream consumers have to know how to handle things and that they need to eject if they see something they don’t know how to deal with. I expect there’s already presidents for this if someone’s got examples.)
I’m also thinking of this like an approach in the Rust programming language where you can have structs (“structured” collections of data where every instance/copy always has the same things in it) and enums (collections of items that are all of the same type/category but have different attributes).
For example, a basic Book struct would have a title (that’s a “string” of text), an ID (that’s another “string” of text) and an Author that’s one of a set of possible options provided by an Author enum. The Book struct would look like this:
struct Book {
title: String,
id: String,
author: Author,
}
The stub for the Author emum begins with this:
enum Author {
}
The first category of Author would be a SingleAuthor that has a name that’s a string of text:
enum Author {
SingleAuthor { name: String }
}
It would also have a MultipleAuthors option that is a group of one or more SingleAuthors (aka an array which is called a Vec in Rust):
enum Author {
SingleAuthor { name: String }
MultipleAuthors: Vec<Author::SingleAuthor>
}
and, finally, an Unknown option that doesn’t have any other values associated with it.
enum Author {
SingleAuthor { name: String }
MultipleAuthors: Vec<Author::SingleAuthor>
Unknown
}
Each Book is required to have an author, but there’s no restriction on which one of the options from the Author enum can be used. So, these are all valid:
Book {
title: "Dune",
id: "abc1",
author: Author::SingleAuthor {
name: "Frank Herbert"
}
}
Book {
title: "The Difference Engine",
id: "abc2",
author: Author::MultipleAuthors(
[
Author::SingleAuthor { name: "William Gibson"},
Author::SingleAuthor { name: "Bruce Sterling"},
]
)
}
Book {
title: "Beowulf",
id: "abc3",
author: Author::Unknown
}
I don’t have the spoons to flesh out this idea, but I wanted to jot something down before lost it.
P.S.
-
This would be better demonstrated using actual lexicons. I don’t know enough about how child/secondary/remote/or-whatever-they-are-called lexicons to do that yet.
-
I’d imagine the same thing would apply to editions, idendifiers, etc.
struct Book {
title: String,
id: String,
author: Author,
identifiers: Vec<Identifer>,
}
enum Identifier {
UUID: {
id: String
// other data, links, etc...
},
ISBN {
id: String
// other data, links, etc...
}
GoogleBooksID {
id: String
// other data, links, etc...
}
}
-
I found this page that lists a bunch of identifiers. Something to look into.
-
It feels like there should be a “Defult” edition if no other edition info is known and that the Identifiers should go under that, but that’s something to play with in the structure.