Maybe we could collaborate?

[Robin-Haupt-1]

Hi Kometenstaub,

i just discovered your plugin because @brimwats commented that i could make my Map of Content plugin compatible to the YAML data yours generates. Like you i have just released my plugin a few days ago.

I love what yours does and it's kind of the same idea i had when i made mine, only mine is based on the idea of creating your own headings and subheadings as notes and linking to those instead of getting them from an official catalogue.

As you'll see mine has some more features like generating a tree view of all notes. If we joined the functionality of both of our addons, we could have a feature that generates a similar view for SKOS tags, also displaying connections that reach through several tags by pulling all the tags related to the ones used in the notes and analyzing them for relation.

I thought i'd hear what you think on this.

Nice name by the way. Are you from Germany too?

[kometenstaub]

Hi Robin,

that sounds promising.

I'm not quite sure how you would want to implement it, though. Currently, with breadcrumbs, when I click on a (e.g. broader) "link", it will create a note for that (because usually I won't have a note of that name in the vault). Normally, I wouldn't want to create a note with that broader heading but rather that it shows me a view with notes that have the same broader heading, unless a note of that name exists already.

That doesn't fit with the current paradigm A) that there must be a defined top-level note and B) that there's always a real note. What you would, I imagine, need to do is see these broader headings as kind of folders.

Would there be a place for narrower and related "folders"? I guess narrower folders would be managed by "broader" and only relevant at the end of the tree. For related, that might be a better fit for breadcrumbs?

These YAML keys would need to be configurable in the settings of your plugin because they can be adjusted freely.

Does what I write make sense? Did you want to approach this differently?

Nice name by the way.

Thank you. :)

related: Robin-Haupt-1/Obsidian-Map-of-Content#26

[Robin-Haupt-1]

One thing i could image is a view that only shows the LCSH tags and the notes related to them, so different from the normal OMOC view in that i doesn't show any relationships between notes.

In there the tags would exist as virtual notes that can't be opened in the editor but still when clicked on navigate the view to that point in the tree to explore the whole landscape of tags. Navigating to the the broader tag of a note would allow one to see all the related ones of the note one came from, i suppose? If all the related ones have the same broader tag / tags that is. I may implement a "sibling" feature in my plugin at some point anyway, that will display all notes that are descendants of all notes that are parents of the current one. If not there could be a custom feature made to display the related one seperately.

That doesn't fit with the current paradigm A) that there must be a defined top-level note

I assume that some tags don't have any broader tags? These could be considered as connected to a virtual Central Note to suit the current algorithm, or there could be a custom algorithm made to take that into account.

These YAML keys would need to be configurable in the settings of your plugin because they can be adjusted freely.

That wouldn't be a problem. Or maybe we could find a way to share this information between our plugins. Some kind of internal API or something...

A different possibility would be to include all the tags as virtual notes with the normal other notes and mix them into the normal MOC view. That would work mostly the same as the first option, but might require some tweaking of the path-finding algorithm to always include the tags even if they're not the shortest path to the note, which is how paths to the note are currently filtered. That shouldn't be a big problem though.

For the path-finding between tags it might be very helpful to have a local index. Is that a prohibitively large file? What made you choose to go with the API for your plugin?

[kometenstaub]

These YAML keys would need to be configurable in the settings of your plugin because they can be adjusted freely.

That wouldn't be a problem. Or maybe we could find a way to share this information between our plugins. Some kind of internal API or something...

this.app.plugins.plugins["linked-data-vocabularies"].settings gives you an object with all the settings. You'll have to declare the Obsidian module with plugins.plugins on app in your plugin because that's not included in the type definitions. See this for an example

Regarding the exact implementation, it would be good to hear @brimwats opinion because they're the expert on linked data and also asked for it, so maybe have the best idea of how it should look.

For the path-finding between tags it might be very helpful to have a local index. Is that a prohibitively large file? What made you choose to go with the API for your plugin?

I started with the Library of Congress Subject Headings because @brimwats suggested it and the data is useful in the context of Obsidian. The LOC also has an API that allows easy (and fast!) access to the data.

You can find the data here, just search for LCSH: https://id.loc.gov/download/

The problem is that the smallest version (SKOS) is nearly 1GB when extracted. So I don't recommend using it in your plugin.

[Robin-Haupt-1]

I agree that I would be good to hear @brimwats thoughts

[brimwats1]

my original suggestion originated from @SkepticMystic's thought here that MOC could show the RTs and NTs like breadcrumbs does https://github.com/SkepticMystic/breadcrumbs/issues/137

but I suspect it's not possible based on the discussion here

[Robin-Haupt-1]

It's not possible now but it may well become possible in future versions. I'll keep it in mind and work on it once the basic functionality of my plugin is fleshed out, i'd say around milestone 0.4.

[kometenstaub]

Just to let you know, I have pulled the plugin for now. See here why: https://github.com/obsidianmd/obsidian-releases/pull/524

I have plans to implement it differently, but for that I think I will need the OK from the Library of Congress. (I want to keep my own JSON with links mapped to headings. That should improve both performance and cut down on requests dramatically.) I'll let you know when I have resubmitted it.

[Robin-Haupt-1]

Oh, that's a shame!

If you need a helping hand i could spare few hours here and there and maybe make some changes to your code. Just let me know what needs some work.

[kometenstaub]

Thank you for the offer, that's very kind of you. :)

I think I'll need to implement it myself, though, because I'm more familiar with the data, but I'll let you know if there's anything I need help with. :)

FYI, that's my current plan:

The data for Controlled Vocabularies is usually freely available as download, it is up to the user to respect the License it comes with. However, this data is usually very large (for LCSH, the SKOS version is ~900MB when unpacked) and too much for using it in Obsidian.

The plan for the future is to have two plugins. One plugin for downloading the Vocabularies and extracting the necessary data. For the extraction, I imagine this to be one JSON file with URIs mapped to the names and another JSON file with the names mapped to the URIs of BT/NT/RT. Every user would need to do this only once. For LCSH, that should not get too big and still work with Obsidian Sync. TfTHacker has done something similar with the Wordnet dictionary. I think it contains ~250,000 entries, has a size of ~30MB and using it with the Fuzzy Suggester is fast in Obsidian. So making two such files should be possible. That way I could also include other vocabs which don't offer a fast querying API and Internet access would only be needed once. This plugin would be desktop only, but the necessary data would only need to be generated one time and users could update it themselves.

Parsing LCSH in ndjson format isn't difficult, that was my initial attempt. However, it requires a node package, which is why it would be desktop only.

The other plugin would be the current plugin, just that it would work with the local JSON files and use Fuzzy Suggesters instead of the current non-fuzzy one. This plugin would also work on mobile, so a desktop computer would only be necessary for the initial download and conversion.

That way, only the first plugin needs to parse different data formats, whereas the second plugin always gets the same data, which should in turn make it very simple.

[kometenstaub]

To give you an update, both plugins are available now in the community plugins.

Please don't access any settings directly in case you want to make your plugin work with it in the future. I think it is better to let users enter settings so that if I make a breaking change, your code is not affected.

[Robin-Haupt-1]

Okay, thanks for letting me know.

I suppose you mean i shouldn't access your plugins settings data in case you change the name or structure of the items? I'll keep that in mind. Or maybe i'll just implement some checks for integrity and make a bot crawl your code for breaking changes so i can adapt to them :)

I'm currenctly preoccupied with other projects though, so i won't get to work on that for a while.