#41

CRMs and social media plugins, for one. I know of other users who already use @ to designate people in their notes. (Not I. I use ꆜ, heh.)

My vote would be to try to avoid the prefix character… I also think an equivalent syntax with dataview makes sense, as then you can use the task metadata in dataview as well!

1 Like
#42

I’m not sure I should comment since:
a) I don’t use daily notes
and
b) I do very little task management (and most of that outside Obsidian),
and
c) I avoid dataview
but I do think there’s a lot of value in consistency across plugins, especially when the values are written into the notes.
(else the same thing is represented by ! In one note, @ in another, and :: ? In another. Obsidian might manage that but, it makes for complicated interpretations when using the notes outside Obsidian, potentially in many years time.

user definable is good. Maybe a plugin definitions toggle wall.

If the chosen system doesn’t suit simple, it will drive some users away from using it

So many plugins, easy symbiosis appears essential for smooth workflows

Please make better decisions that the markdown specifiers

#43

I guess I don’t see these as a conflicting, though, unless these systems used the same overall structure. Eg, @___:: [[<date>|<optional date with time>]]

I could see there being a slight conflict in meaning: - [ ] Send email to @joebob

But the structure also offers some clarity in the regard as well: - [ ] Send email to @joebob @due:: [[2021-11-05|2021-11-05 1:00pm]]

In this case, there is some ambiguity for a plugin developer implementing @ mentions, but having a community defined date format could help with this, in that there would only need to be a single edge case they’d have to address.

Also, as a user, I guess I would prefer a prefix character because it could reduce the amount of typing needed if it triggered a date selector.

3 Likes
#44

I think this is it. Nailed it.

How could we integrate this structure into the existing task management plugins? Apart from this thread, is there any communication happening?

I believe some sort of standard library to be shared when compiling seems like the place to go. I’ve seen some examples in this thread already.

1 Like
#45

This sounds like a great solution.

Especially in combination with this:

With the @ being replaceable by any of the other symbols and used in conjunction with the word (Due, etc), a (double)colon and [[DNP]]

perhaps ‘do’ and ‘due’ could be basic standard options. And perhaps a standard library of other meaning assigning words could be built over time, and become user-defined (e.g. in the settings, set the word for start date, which could be do, or start or defer, as long as it is sandwiched between the symbol and (double)colon). These may or may not work in all plugins, but in those that do would be interoperable. and the [[DNP]] would still work even if the chosen plugin does not support a given word (eg defer).

TLDR;

@___:: [[___]]

symbol: user defined
double-colon: works with dataview (if I understand correctly) and makes it unique structure easy to parse
[[___]]: works with backlinks, NL plugin and DNP

If possible always parse @[[___]] as due date for super simple use.

How’s that?

1 Like
#46

As I mentioned before @, is used by Pandoc/citeproc for citations (@JohnDoeAIwork_07) and it is fairly standard at this point. I wouldn’t touch @.

I think a prefix @ AND a suffix :: are too much. I am not convinced that the regex is so much more complicated to justify both a prefix and suffix. Dataview works. (I am not a dataview user)

IMHO due:: [[2021-11-04]] and do:: [[2021-11-04]] is enough.
You can trigger the date selector after the second :.

6 Likes
#47

Is the worry RE: citations that something like @completed:: [[2021-11-04]] would be parsed by pandoc as a citation key? Or is there some other way these formats would conflict?

Re: just using ::. The worry here isn’t so much the complexity of the regular expression, but the performance. It’s definitely doable, but if we only use :: then we have to check every dataview key we see. This might not be a big deal if we limit the scope to task items, though. Also triggering a date selector on the second : would bring it up every time a dataview key is typed. We might also run into false positives here, too

I think we’re all honing in on some fundamental design issues, which is great. One way we can approach next steps is to compile a list of things that are must haves, and things that are choices to be made, and get some broader community feedback on them.

For example:

Must haves we’ve discussed thus far

  • Uses dataview inline metadata format
  • Uses daily note date format
  • Supports time
  • Supports label to assign meaning to a date
  • Supports links to daily notes
  • Supports not linking to daily notes

Nice to haves

  • An abbreviated format when a label isn’t necessary

Design decisions to be made

  • Special prefix character or no

Other considerations

  • Parsing ease
  • Parsing speed
  • Minimal collisions with other plugins / data formats
  • Minimal false positives
  • Ease of offering autocompletion

Am I missing anything, or have I misrepresented anything here?

5 Likes
#48

The only thing that I would argue is a MUST is natural language support - the plugin already exists, so it surely should be easy to integrate? Being able to say ‘next Friday’ is a huge help, as opposed to having to go and look up a calendar to see what date next Friday actually is.

ezgif.com-video-to-gif-2

4 Likes
#49

So, here’s my best attempt at summarizing everything so far. This is largely my voice, and I welcome any input here.

3 Likes
#50

And here’s my proposal. I’d love to see some others as well. We can take a poll on discord or something.

4 Likes
#51

I think this is a great summary and a great proposal!

NB:
I’ve re-uploaded my gif as I realised it cut off the important part (i.e. next Friday) :roll_eyes: - my trigger phrase for dates for the Natural Language Plugin is a semicolon (hard to see…)

thanks again for all your work on this!

1 Like
#52

I like this.

There is a potential ambiguity though if using the optional linked date with time format as there are 2 places you provide the date and they could be different. If the optional part only contained the time then this would not be an “issue”.

#53

That’s a good point, I realize that we could just do @due:: [[2021-10-09#2:00 pm]] This has the added benifit of rendering out both the date and time in preview mode. I wonder if there are any issues with the headings not existing, though? I don’t see any in my tests.

Screen Shot 2021-11-05 at 9.46.57 AM

This makes backlinks a little cleaner, too

Screen Shot 2021-11-05 at 9.48.59 AM

#54

Yes. and if somebody writes a citeproc plugins for obsidian everytime a @ is typed a popup menu will appear to make the reference selection (like zettlr currently does).

No because you would trigger the date selector only if the preceding string is due:: not just if there is :.

If we limit the scope to tasks and don’t care about maintaining uniformity with dataview, we could just do: !due [[date]] and !do [[date]]

4 Likes
#55

I am adding another voice in favor of phasing out @ for task management plugins. As someone who helps a lot with troubleshooting in Discord/Reddit and gets emailed questions pretty often, my motivation is purely selfish: It exhausts me to have to explain to confused people how @ is both how the community orthodoxy (a LOT of people watch Bryan and Nick’s videos) handles people and how the community plugins handle task management and how the community workflows handle citations.

The current situation is one thing, but couldn’t be avoided because Twitter and Discourse and Discord use @person and Pandoc uses @citekey.

But we can avoid it here and I haven’t yet heard a good argument in favor of using it.

10 Likes
#56

Not sure if this is exactly relevant to this discussion, but is there a way the plugins could allow the ability to user customise it - essentially allowing users to use a format of our own that aligns with the moment.js syntax?

For example, my daily periodic notes are created with the title (for example), “1ABCDE-YYYYMMDD”, and the natural way for me to use task management plugins would be to allow me to link to these pages directly. I haven’t been inclined to use NLDates or most of the date/day functions in task management plugins since it seems most of them default to “YYYY-MM-DD”, which is exactly not how I name my daily notes.

#57

Yes, the date format should definitely be customizable. From the discussions so far, we’ve talked about relying on the daily note date format which can be customized.

Also, NL dates should already support customizing the output:

Screen Shot 2021-11-06 at 12.58.58 PM
Screen Shot 2021-11-06 at 12.58.58 PM1540×460 12.9 KB

1 Like
#58

Two cents: I’ve reviewed the appropriate ontologies and standards (i.e. Dublin Core, SKOS, RDF, RDA, and OWL^1)

The generally-accepted datetime format is

dct:date and then "1999-01-23"

in obsidian this would be a colon and date link, i.e. — date: [[YYYY-MM-DD]] or date:: [[YYYY-MM-DD]]

standards organizations recommend against the use of @ as it is used for languages or people (i.e. term@en-us or person@domain.com

[1]: OWL, of course uses a semicolon, but that is because of RDF. i.e.: <premiereDate rdf:datatype="&xsd;date">1900-01-14</premiereDate>

4 Likes
#59

And @EleanorKonik and @WhiteNoise

I’m pretty sure that the proposal was to have the symbol be user-defined, just like making use of the daily notes format, which is also user-defined, or whether the daily notes dates are linked.

So basically what @mgmeyers proposes, but with these settings:

  • do you want to use the standard date format? (Yes/no)

  • which symbol do you want to use? (Defaults to ! If not defined)

  • use DNP (as defined in core settings) with links, or as plain text?

#60

Sorry I am late to the party and thank you @EleanorKonik for your “Obsidian Roundup” :smile:

I agree that it would be awesome to have a unified standard for dates and I like a lot what I read so far. Thanks a lot for bringing up this topic.

In short: I would be happy to add support for a standardized format to Tasks.

My two cents (when I say “Tasks”, I mean the plugin):

  1. I would prefer we stayed away from @ for the aforementioned reasons. I think the drawbacks are too heavy.
  2. I am in the process of adding custom date formats and links to Tasks. This means, it will be possible to have [[2021-11-07]] in Tasks anyway.
  3. I think it’s not much work to support due:: in addition to :date: and so on and I’d be happy to add support for “standardized signifiers” (see also point 6).
  4. Tasks won’t support time in the foreseeable future. This means [[2021-11-07]] without a time must definitely be an option.
  5. Tasks will support a list of date formats, but Tasks will not support user defined formats.
    In my opinion, it’s a bad idea to update all existing tasks when the user changes the format. Old tasks should stay untouched, for example to respect the “last time a file was modified”.
    For that reason, Tasks should always be able to parse all tasks that are written in any one of the allowed formats.
    Allowing the user to pick a new format without updating all existing tasks would mean Tasks couldn’t parse older tasks’ metadata anymore. In my opinion a no go.
  6. The same is true for “signifiers” like due:: or :date:. I am happy to support a list of those including a standardized due:: (or whatever we end up using), but Tasks will not support user-defined signifiers/labels. As a side note, the semantic information of due vs. scheduled is important to the tasks plugin and not only to the user. Tasks must know which label belongs to which date.
7 Likes