Suggestion for all Plugin developers about field name: Let's use Ontology to maintain Interoperability

[linonetwo]

Ontology is the dictionary that a community shares. It will improve interoperability between plugins.
Let me explain!

Interoperability: For example, I’m trying to develop my GTD plugin, and found there are many existing plugins but stops developing. So if use tmo:dueDate as the field for the task’s due date, other GTD plugin that is reading the same field tmo:dueDate can read the user’s todo tiddler, and two GTD plugin can work together.

We can see the Projectify plugin and GSD5 plugin can’t work together seamlessly. But each of them has some handy features, we really hope the whole community’s plugin can work together. This “work together” is what Interoperability is about.

Ontology: We know it is hard to think about “what field name I should use, so other plugin developers can agree with me to use the same field name”. Lucky, Some experts have made their efforts to write down these field names, and listed them on the website like https://www.semanticdesktop.org/ontologies/2008/05/20/tmo , which contains a dictionary of field names. These dictionaries are called Ontology.

Let’s use ontology!

I suggest when we develop a new plugin, we first search for the ontology that we can use. If everyone does so, our plugin will create the same data, and the user will find that their tiddler become so powerful that can power many plugins to work as a chain.
And aggregator like DynamicTable will be able to display the fields of all your plugins in very few columns. Without needing hundreds of columns to display all fields in your wiki.

Using the same dictionary will make us work together more tightly. And will make user fell their tiddlywiki more productive and clean!

How to find Ontology you want?

Let’s search here GitHub - taurenshaman/semantic-web: Storing ontologies/vocabularies from the web. Wish anybody can translate some of them.
It contains dictionary in both English and Chinese translated.

For example, search for task-related concepts: Search · task · GitHub

After the search you will find website links like http://www.semanticdesktop.org/ontologies/2007/01/19/ , you can view these websites to find detailed comments about these fields.

Fell free to ask me anything about ontology

I was working in the SoLiD project, so I’m very fremiliar with these things, if you feel confused or need some help finding your field name, feel free to ask me!

[jeremyruston]

Hi @linonetwo good idea.

@linonetwo

I was working in the SoLiD project, so I’m very fremiliar with these things, if you feel confused or need some help finding your field name, feel free to ask me!

Interesting! SoLiD is a good implementation of an old idea, and it’s great to see it develop traction.

[TW_Tones]

@linonetwo I think this is an important idea. I suspect it needs to evolve somewhat within the Tiddlyverse because tiddlywiki introduces a great deal of flexibility that we do not want to “crush” yet also providing suggested ontologies or even just documenting them will be very powerful. The ability to stand on the shoulders of previous work is as valuable as the interoperability that this can support. So for specialise uses we document the “reference” ontology so others wanting to integrate can with ease, but do we need one or more tiddlywiki ontologies?

Here are a few thoughts to stimulate consideration;

• Plain language is best for readability and self documentation, but is perhaps more likely to conflict, yet if handled well will support compatibility.
• prefixes or suffixes help reduce clashes but they do often make things less readable
• some solutions are stand alone and may not need too much compatibility others are the opposite and must by definition integrate with others.
• Solutions that let you configure them can allow the implementation to be customised during integration, Relink plugin and custom settings can help a lot.
• Many solutions have a small scope and need only participate is a limited ontology as per your todo/task management
• Smart self documentation can go a long way to exposing a solutions ontology
• More advanced opt-in field definition tools would be helpful, then a second solution would indicate when it is defining the same field name.

Can an ontology be smart?
For example I have found the need to assign multiple URLs to one or more tiddlers, I could have a standard “link” field and then extend this to be a suffix eg discussion-link … but I could also make use of the content of the field to determine how to use it such as if a field starts http:// https:// then it is a link. But how do I handle setting target or pretty link titles? suffix “-link-target”.

[linonetwo]

@TW_Tones

providing suggested ontologies or even just documenting them will be very powerful.

I would encourage people to show off the field names used in the plugin, when posting plugin release notes in the talks forum. I think we can be proud if we are using some ontology (which will make the community better).

And I believe before we create some plugins, we will first search for previous works, then we will find ontology suggested by previous contributors.

@TW_Tones

prefixes or suffixes help reduce clashes but they do often make things less readable

Actually, the prefix is a kind of “backlink” or “comment”. You see, if we just search " dueDate" in google, there won’t be many meaning full results. But if search tmo:dueDate, well, at least you will find tmo’s website, and its comment and usage suggestion about tmo:dueDate:

And I hope all fields can have their “bluebox” (from gsd5) in the future, so the actuarial field name won’t be visible to the end-user. (I’m learning how to use the Cascade to add field editing widget to tiddler recently…)

So I think it is worth using the prefix.

[linonetwo]

@TW_Tones

Many solutions have a small scope

Yes, this is just like a private variable in the class (Java class for example). Whether make a variable public or private is upon developer to decide.
Using too many private variables will harm the interoperability, while too many public will introduce breaking change if he is going to use that variable in another way in the future. This may be upon wisdom to decide…

[TW_Tones]

@linonetwo

ut if search tmo:dueDate, well, at least you will find tmo’s website, and its comment and usage suggestion about tmo:dueDate:

I am not sure a field level search string using the prefix is helpful, instead I would hope an example like “tiddlywiki brand projectname” would be unique. I just searched “tiddlywiki psat” with some success, then “tiddlywiki PSaT mymenus” is as well.

[linonetwo]

@TW_Tones

“tiddlywiki brand projectname”

I think these fields can be also used outside of tw, so I suggest using standard ontology prefix instead of tiddlywiki prefix. Then each tiddler can be regarded as a JSON-LD, and be used by web3.0 infrastructures like GitHub - comunica/comunica: 📬 A knowledge graph querying framework for JavaScript

This is the future, I hope I can introduce some AI into my wiki.

[joshuafontany]

Interesting idea! I have explored ontologies, and that’s what led me to some interesting tools like VUE & eventually Tiddlywiki. I think a baseline definition would be useful for the community to continue this discussion.

Ontology

• a set of concepts and categories in a subject area or domain that shows their properties and the relations between them.

This is why @linonetwo discusses field-prefixes. Ontologies are DOMAIN or SUBJECT AREA specific. So, plugins that use “To Do List” concepts within TW would find a “common language” if the plugin authors used the same Ontology when designing and coding their tiddlers. Similarly we would need a “TW5-Contacts List” Ontology for that design goal, or a “TW5-RPG” Ontology to talk about role-playing-game specific functions/features/tiddlers.

[TW_Tones]

@joshuafontany

a baseline definition would be useful for the community

Perhaps a plugin for each “ontology” is enough to define the set of tags and fields that one may use for a particular subject. Plugin tiddlers containing fields and tags end up available through out the wiki once they are installed. So lets say I am building my own todo solution, first I install the “todo ontology plugin” and now the various fields and tags are already available.

Here is a very simple example $ _PSaT_todo_ontology.json (154 Bytes) you can drop on empty. html effectively adding two tags and two fields to the wiki. Obviously it could contain more info, even more tiddlers documenting the todo ontology.

This above adds these “tiddlywiki objects” fields and tags in a system tiddler, but would be used when !is[system].

Quite complex ontologies could be made available to a wiki by this method, and yes they could have todo:prefix etc… if desired. Include filters, lists, templates etc… for the different instances lists etc… using the contained ontology.

[pmario]

I do like the idea to use existing definitions to define field names. … This feedback is very specific to the tmo:dateTime element mentioned in the OP …

@linonetwo

So if use tmo:dueDate as the field for the task’s due date, other GTD plugin that is reading the same field tmo:dueDate can read the user’s todo tiddler, and two GTD plugin can work together.

If you have a closer look at the spec in your link you will see, that the “Range” parameter of tmo:dueDate is of type xsd:dateTime

If you have a look at the spec for xsd:dateTime you will see, that it comes with some “Restrictions” that forces us to use new converters to create output formats we (the end-users) are used to.

The main problem is, that the TW core doesn’t have any conversion mechanism, at the moment, to “format the output” in a way we are used to, if the starting point is derived from tmo:dateTime.

TW uses a visible format, that is similar to ISO 8601 UTC format: 20220101T103207Z for modified and created fields

Internally the modified and created timestamps are stored in the UNIX time format. Milliseconds since 1.1.1970 – it’s only shown in the way we are used to.

There is a PR on the way, that should allow us to be more flexible creating “timestamps” that are “normalized” to the UTC visual timestamps TW core uses. …

[linonetwo]

@TW_Tones

effectively adding two tags and two fields to the wiki

Will it be possible to auto add/validate fields while adding a field? Like using tag as a JSONSchema?

[TW_Tones]

@linonetwo first let me say I am very keen for us to develop ontologies to act as shared de facto standards so we can encode more information about a field however I think this is a broader subject than even what you propose for two reasons.

@linonetwo

Will it be possible to auto add/validate fields while adding a field? Like using tag as a JSONSchema?

With the concept of field definitions, Yes.

• Rather than use a naming standard such as tla:duedate I could just use duedate then “scope the use” so duedate found only on tiddlers with the field object-type=task will it use the format YYYY/0MM/0DD.
• Providing a mechanism to define a field and set a field type with its view/edit and update handling is another way to handle more complex definitions. Add to this the ability to add a scope to which it applies and there is no need to change the fieldname with a prefix.
  • for example another plugin can use duedate say for projects, or it could be used for baby’s duedate

tla = three letter acronym

Perhaps the key here is to start with a field called ontology. I could use my brand “PSaT” which says all fields here are defined within the PSaT onlology or another.

Then since the tiddler is the basic piece of information within tiddlywiki one or more ontologies can be used at the same time, either a standard and common one, or a custom and individual one. This is related to the concept of a “name space”.

Background: I am a “Solutions Developer” and I do not need plugins or Javascript to produce tiddlywiki solutions.

To be clear, a field in a particular scope can be given a field-type of xsd:dateTime meaning it is defined by the xsd:dateTime specification, but it need not be the fieldname.

[pmario]

@pmario

There is a PR on the way , that should allow us to be more flexible creating “timestamps” that are “normalized” to the UTC visual timestamps TW core uses. …

As I wrote, there is a PR on the way. This PR contains a link to a demo wiki, which uses different templates to edit “named” fields. … Go to the link and have a look at the demo fields. …

At the moment the field names and input templates are only active in tiddler edit mode. … It should be possible to create “default” UIs based on field-names. …

The field name is related to the template name. So any namespace can be used.

The demos are date-related, but it can be any value and type.

[linonetwo]

@TW_Tones

Rather than use a naming standard such as tla:duedate I could just use duedate then “scope the use” so duedate found only on tiddlers with the field object-type=task will it use the format YYYY/0MM/0DD.

Understood, this is like the context in JSON-LD, I can provide a plugin that includes a TMO tiddler, with field @context.@base: tmo. Then if a tiddler adds TMO tag, its field dueDate will be regarded as tmo:dueDate. And we only use prefix if there are ambiguity.

@pmario

At the moment the field names and input templates are only active in tiddler edit mode. … It should be possible to create “default” UIs based on field-names. …

Yes, I’ve seen the demo, it is very promising. Seems that fromValueFilter can aware of the tags (because it uses standard filter expression), so we can make “if tiddler that adds a TMO tag, then its dueDate field use a specific DatePicker”.

I can make use of this, to build a $:/ontology/tmo plugin, which has a TMO tag, and many fieldEditor, and some snippets to add create-tiddler-button that can add TMO tiddler on a click. And that tag will contain necessary human readable content to explain what tmo is.

[TiddlyTweeter]

Ciao @linonetwo.

My 2 cents on your points. The tech side of what you pointing at is beyond my competence. But the positive outcome side I think I do see clearly.

To give a more prosaic example in ordinary usage I’d point to the problem of un-cordinated “shared tags” (i.e. you end up with multiple variants). This is extremely clear in the otherwise excellent TiddlyWiki Links - Topics. For instance …

That redundancy, I think creates fog. It makes things over verbose and more difficult to use than they could be. I’m pretty sure one harmonised term would be much better than three. But in order to do that there would need be some kind of reference index of preferred tags.

One part of the issue is the end-user (sensibly) wants to develop a terminology (a folksonomy) fitted to their immediate needs. And TW absolutely (correctly) provisions and supports that.

But, issues arise, as you point out, as soon as one attempts to share collectively with maximal shared leverage.

What interest me in this issue is both the deeper issue you point to and the more generic problem of “shared language”.

FYI, as a bit of fun, I have to say, as someone who has a philosophical bent, that the term Ontology slightly raises my hackles as the Real McCoy is somewhat broader than “nameology / onomatology.” But this is more a joke comment than a criticism .

I’m interested to see where this leads and if it may also address more than architectural inter-working needs. Like, for instance, the whole area of publicly shared tags.

Best wishes
TT

[linonetwo]

A nice field name (ontology) search engine https://shaperepo.vercel.app/

[linonetwo]

My latest try to push the idea in this post forward: SuperTag plugin, auto-generate a field editor on view template - #4 by linonetwo

The Ontology in this post are TraitTags in the SuperTag plugin. Developers can share those TraitTags, so our plugins use the same field names.