Additional MetaData

Hi, I’m a minister and would like to talk about adding a feature to Joplin to make it usable as a Sermon depository.

When I preach a sermon I like to track the date it was preached and the location it was preached. One sermon might have multiple dates/locations. Is there any chance this could be implemented as a feature? Maybe as a tab to the Note where multiple dates and comment fields could be added to the Note.

Any chance someone would be willing to offer a quote of what it would take to do this?

1 Like

And before someone says, Use Tags for this. I’ve tried that but tags are too freeform. I need something more structured that will keep the list of dates/locations sorted in order of date. Also I use tags to add the scripture passages and keywords to the sermon.

Maybe a dumb question, why don’t you just keep track of those things in the note itself? I’m not really seeing why you would want it in metadata?

If it’s because the info clutters the note I can show you how to hide stuff from rendering in markdown.

I thought about that but i just dont like it in the actual note itself…

What you can do is use an html comment in your note, this will allow you to place information in there without it being visible in the rendered markdown
For example

Some sermon notes
Some really long sermon notes

<!---
Date: 2019-08-01
Location: Jerusalem
Etc.
-->

This allows you to add additional data to a note without it being visible when you look at the rendered view.

Another thought.

You could simply keep another note where you store a list of all the sermons you’ve given (using Joplin note links) and each corresponding time you’ve delivered that sermon.
This would keep your actual sermon notes clean and still give you a method of keeping track of metadata.

I’m using Joplin to store some of my genealogy sources and other historical research, and store things in a similar that you want…

I make use of the Joplin Notebook and Sub-Notebooks feature for that…
So what you could do is to make a Sub Notebook for the Year in your main Notebook, under this you make Sub Notebooks for each preach you write and create a Notebook name of i.e.
YYYY-MM-DD - Name of preach (the date format is for sorting)
… then under this Notebook you make a Note with the Text it self
… And then you make a Note for each Sermon you hold with the dates and any Notation you want to add for that Sermon…
The structure will be something like this…

Main notebook

2019-07-24 - The Preach of Golden Opportunities (Notebook)

---- 2019-07-24 - The Preach of Golden Opportunities - The Text (Note)
---- 2019-07-25 - Salem Sermon (Note with additional inf. regarding the location and the Sermon it self)
---- 2019-07-30 - Gettysburg Sermon (Another Note with additional inf. about the Sermon)
---- 2019-08-01 - Rewrite and adding text after some feedback

2019-08-02 - The Preach of Good Faith and Kindness (Notebook)


You can also use To-Do Notes for this if you are planning the locations up front, and want a way to check of the Cermons after…

And with the Joplins feature of Linking, you can actually make multiple different Hierarchies, and Make linkes to Notes in any of them, so you can build up any logical folder structure for your Notes …
i.e. If you want all of your Sources and Citations in a specific Notebook hierarchy for easy reuse…
You can actually store the whole Bible in a hierachy where the Bible is the Top Node and Books are Sub NoteBooks and each Verse is a Note…

Just my tip of how to do it today… This way, you can also add Notes with Citations to any Sources you have used, either by adding a file to a Note or Using the Web Clipper to make a copy of Internet Sources… or just by copy Text to a Note…
And you can make a Note Template for the some of the text and structure of the Notes

I’ve thought of all the different ways it could be done. But the way I want to do it is how I described it.

I understand that, but you will actually have a lot more control using notebooks and sub notebooks… and you can use internal links in the Notes, to get even more control…

But, I understand what you are saying, I’m used to using Metadata as a photographer and researcher…
I use Zotero for all my sources, and Joplin as a Research notebook…
And a DAM solution for photos and docs…

I think the idea behind this request is great.

Imagine you are dealing with bills or invoices for instance. Tags are perfect to flag them as #invoice and #water for instance. Having the ability to define additional metadata could show very useful.

For the #invoice example, you could add an "amount" value for instance.

Using the overview plugin, that would allow you generating a list of your invoices and show the amount of your invoice. Tags cannot be used to store this "amount" information.

Since the number of fields is fixed, I could imagine adding a new "user_data" (I see an "application_data" already) that would hold any piece of valid json under the hood.

In my invoice example, an #invoice note could have "user_data" = { "amount": 42.38 } for instance.

Similarly, you imagine someone doing sport and who want to keep track of his/her runs, notes could look like:

  • #run #1km #2021 user_data: { duration: 600000, maxPace: 42 } ( 600000ms = 10 minutes: 10 x 60 x 1000)
  • #run #10km #2021 user_data: { duration: 6300000, maxPace: 37 }

If the overview plugin from JackGruber/ (GitHub - JackGruber/joplin-plugin-note-overview: A note overview is created based on the search and the specified fields.) could use fields such as "user_data.duration", it would generate great summaries.

Exepanding on the topic but this one may be more intrusive in the current architecture would be the ability to attach a schema to a tag.

Using the examples I mentioned above, a user could define a tag #run with a schema such as:

{
   duration: number,
   maxPace: number,
}

or using a standard such as Getting Started Step-By-Step | JSON Schema

This would allow client apps, to built some UI for the input of the relevant info when a given tag with schema is added.

As far as I am concerned, the ability to attach an extra piece of json would already be a great start.

1 Like

if you have a metadata format/standard you want to use, why not just add it to the bottom of the Joplin Note?

eg.

<div xmlns:sermon="some format URL">
    <sermon:date>2021-01-20</sermon:date>
    <sermon:location>New York, NY</sermon:location>
</div>

wrap it in <pre> tags and it should survive exporting to HTML...

just an idea

The benefit of supporting it in the core is that you can build the UI around that and add support in the queries as well as when displaying results.

So the answer to your question is similar to using tags/labels vs throwing some keywords inside the note. I also don't really think adding XML (or even JSON) inside a note, is a nice solution for "regular" users (read: non developer...).

The idea here is more to say for instance that the tag "invoice" requires an amount (which is a random number) so when you flag a note with "invoice", the UI shows up the amount field that you should/must fill up.

This would allow extending queries to more than "find me all notes with the tag invoice" to "find me the notes with the tag invoice that are more than $10".

NOTE: The "invoice" examples are only examples...

Moreover, taking your example (thanks for providing one btw) can become overly complicated.
Consider the following (example...):

  • an invoice tag requires an amount (number)
  • a "club" requires a "name" (string)
  • a "tax" tag requires a year

Just generating the XML/JSON for this simple example will be hell and will pull you out of what you are doing. You are adding a note about an invoice for your football club, the time is not to think about XML or JSON. where the user just wants to create a note, for an "invoice", that will count in the "tax"es for the "club" XYZ.
The user only needs to set the tags that make sense and the UI can request the extra data that will later allow building reports of all the invoice, for a given club, for a given tax year.

Addionnal metadata is good to:

  • search
  • display results

Admitedly, when the metadata is a single string such as "invoice" or "2021", tags do the trick.
In your example actually, the location is a string so it totally could be a tag. The date however, would benefit from being understood as a date in a similar way I mentioned with the invoice amount.
You could use tags (I actually do that...) for the year. That helps finding all the notes (sermon in your case) in 2017, or 2018, or not 2020, etc... but it falls short when it comes to finding all sermons from summer 2019 unless you add your custom implementation.