Turning the objects into RDF structures will be trivial. I'm currently not
planning on running a triplestore with those structures loaded (just as I
didn't when Wikidata was started), but I can totally see the benefit of
doing that. I think Lydia would very much prefer not to load it into
Wikidata's query service, as that one is already creaking at the seams. But
yeah, I would hope that such a thing would be set up. You are right,
querying that would be lots of fun.
On Thu, Mar 16, 2023 at 7:56 PM Thad Guidry <thadguidry(a)gmail.com> wrote:
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/
_______________________________________________
Abstract-Wikipedia mailing list -- abstract-wikipedia(a)lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikime…