I thought about not writing anything yet... but then the queryable topic
was just to important not to speak out about now rather than later.
I'd definitely go for Option 2. This has several benefits:
1. queryable - What's the point of making structure, if we cannot query the
structures en masse? There's no point in making structures then in the
first place. Are we saying that we don't want to include abstract content
in the database of knowledge? It doesn't have to be queryable via SPARQL, *but
abstract content needs to be queryable*. Not being able to query abstract
content will be a complete non-starter for me and likely many other
contributors later on.
2. RDF tool extensions later on can be developed to understand the abstract
content structures; so I'm not worried that it won't be queryable later on
given some time for tooling to develop.
3. The UX is something that will need to "break the mold" certainly, but it
needs to be and probably a good thing to start doing and working forward on
toward a design system around *context control *where historically that was
namespaces, but that segments the relationships of items too much and makes
tooling, metadata, and many other things much harder. One possible way
that works across all browsers is <iframe>. Simple, ancient tech yeah, but
it also has the same effect as the tab option since it can encapsulate even
an entirely different app (Vue3?) within the same viewing window of
browsers. The downside is that the HTML page indeed grows larger in size
(<iframe>'s are embedded in existing pages), but showing and hiding
<iframe>'s is trivial and can be a preference.
In the end, we can see that through all the options you listed and maybe
others, we are looking for a good hard relationship between an Item and its
abstract contents. Some of the options make this explicit, and others
implicit. I'd go for explicit with option 2 by having the new
datatype, that automatically brings the ability to add new metadata when
the future needs arise (like we've done before for certain datatypes),
which is something that will be needed for context, such as your examples
of "history", "etymology", "wikivoyage", etc.
Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/