In-text semantic annotation of links

[felixhayashi]

Motivation:

• Allows users to expose the meaning of links in a machine readable way.
  • …so e.g. plugins like TiddlyMap can make more sense of it.

How others do it

Semantic MediaWiki uses the following notation

Make [[Example property::link|alternate text]] appear in place of the link.

See https://www.semantic-mediawiki.org/wiki/Help:In-text_annotation

What needs to be done:

• Extend existing regular expression for parsing links
• Extend $tw.wiki.getTiddlerLinks or create a new function
• Extend the link widget

Related

• In-text semantic annotation of links felixhayashi/TW5-TiddlyMap#119
• Include link text for links retrieved with getTiddlerLinks() #1749

People previously involved

@tobibeer @Jermolene @ybabel

[Jermolene]

Hi @felixhayashi seems like a reasonable idea.

[ybabel]

If I'm not mistaken, SMW link are reversed from TW's :

• [[Displayed Link Title|Tiddler Title]]
• [[Example property::link|alternate text]]

"alternate text" is equivalent to our "Displayed Link Title"

So I think the right syntax for us should be rather (in order to keep ascendant compatibility):

• [[Property::Displayed Link Title|Tiddler Title]]
• [[Displayed Link Title|Property::Tiddler Title]]

not a big deal I think ;-) I'm just mentioning

[felixhayashi]

not a big deal I think ;-) I'm just mentioning

good point! should be [[Displayed Link Title|Property::Tiddler Title]] then. [[Property::Displayed Link Title|Tiddler Title]] is not appropriate here as the property should be paired with the real tiddler title and not with the alias.

[tobibeer]

the property should be paired with the real tiddler title and not with the alias

While that is true, I don't quite think I would overload the wikitext syntax either way. I'd rather try and find an appropriate spot to extend on it, something like:

[[pretty|title]{property:value;prop:val}]

[felixhayashi]

[[pretty|title]{property:value;prop:val}]

Why does a semantic annotation need value and what is its meaning?

I think [[Displayed Link Title|Property::Tiddler Title]] looks good, why deviate from existing wiki markup and make it harder for e.g. SMW users to understand TW's wikitext. Also [[pretty|title]{property:value;prop:val}] is difficult to parse as it creates cases were links are not wrapped in [[…]] but inside [[…}].

[tobibeer]

I think [[Displayed Link Title|Property::Tiddler Title]] looks good, why deviate from existing wiki markup and make it harder for e.g. SMW users to understand TW's wikitext.

What would you refer to with SMW?

Other than that, using link-syntax in your proposed way breaks backwards compatibility and disallows titles involving double-colons.

I suggested object notation because it cannot be anticipated what properties maybe used to qualify a relation / link. TMap may use an entirely different set of qualifiers (and different allowed values for each) than some other plugin making use of any semantically enhanced relations.

For example:

[[pretty|title{tmap-edge:"parent of"}]

How would you possibly just be using "parent of"? Why (artficially) constrain the expressivity of such a relation ...to being mere "identifiers"? ...or even just one?

Would you support:

[[Displayed Link Title|property-B::property-B::Tiddler Title]]

?

What If I actually need a key-value pair for each property? Once we are stuck with identifiers, there's hardly a way to enhance that for key-value pairs. So why start off with limiting modeling paradigms?

[pmario]

hmmm,

IMO not core but may be plugin!

I think, there should be only one place to add properties to links. So using the Berlin is the capital of Germany and Berlin has 3,396,990 population. I think we should have a customized link widget plugin, that allows us to add meta data to the created html output.

The properties and the prop-content should be part of a tiddler. IMO "the tiddler is the thing"

We have several other problems to solve here:

eg: property names ... capital of vs hauptstadt von ... "the tiddler is the thing"

eg: number format: 3,396,990 is not a number for German users. It would need to be formatted like
this: 3.396.990 if the Control panel says so! But needs to be stored like this: 3396990

-> What if this number changes? ... I don't want to change every tiddler, that may contain this info. ... "the tiddler is the thing"

So if we want Meta data, we should do it right.

• Allows users to expose the meaning of links in a machine readable way.
  • …so e.g. plugins like TiddlyMap can make more sense of it.

Nice idea, but I doubt, that TiddlyMap can make sense of a string like this: 3.396.990 without the information, how to use it. So we need some schema definitions. see: http://semanticweb.org/wiki/Semantic_Web_standards.html ...

I like the idea, that I could export an appointment setting from a TW to a Calendar app in VCalendar or any other format.

[tobibeer]

Nice idea, but I doubt, that TiddlyMap can make sense of a string like this: 3.396.990 without the information, how to use it.

In this construct:

[[pretty|title]{tmap-key:tmap-val}]

...tmap would very well "know" how to use it, because it would have been created based on the very instructions that tmap provides in how to handle / define / create such wikitext.

[tobibeer]

http://semanticweb.org/wiki/Semantic_Web_standards.html

I'm not sure I see much of a relation between tiddlers in a TiddlyWiki and something like RDF... but maybe that's short sighted on my end.

I also don't think that for every turn we make we need to pick and chose and then implement some third party standard... unless someone clearly communicated very specific benefits of why and how to use any of those.

[felixhayashi]

@tobibeer

SMW meant Semantic MediaWiki, which is a project to give MediaWiki semantic wiki abilities.

[[pretty|title{tmap-edge:"parent of"}]
How would you possibly just be using "parent of"? Why (artficially) constrain the expressivity of such a relation ...to being mere "identifiers"? ...or even just one?

This is independent of TiddlyMap. Semantic wikis allow the user to define the meaning of links. So you have a subject (the article that holds the link) a predicate ("parent of") written along with the link and an object (the link target). You don't need tmap-edge:"parent of" as the meaning of the link is universal and doesn't need a prefix. Of course you could use a vocabulary like "FOAF" but in this case you would write [[Displayed Link Title|foaf:parent::Tiddler Title]] and foaf:parent is the property.

If e.g. TMap parses the text it will construct the following edge: "TiddlerA - parent of - TiddlerB"

[[Displayed Link Title|property-A::property-B::Tiddler Title]]

Usually one property is enough. But I agree that there are (rare) cases in which it may make sense to describe a link with multiple properties.

@pmario

Nice idea, but I doubt, that TiddlyMap can make sense of a string like this: 3.396.990 without the information, how to use it.

I am not sure if we are talking about the same thing and maybe it is my fault because I wrote in the intro "This would bring us one step closer to a semantic wiki" (I deleted this phrase in the OP). I am only talking about annotating links/relationships to other tiddlers (as the issue title states). You are right, semantic wikis go a step further and also annotate data, "331313 = number of citizens in X" but this is not what I aim at. I just propose to allow users to state in their links what the link is about, that's all.

I don't think this is plugin territory. Giving a user the chance to state the "type" of a link is pretty common, a very simple addition and would enable many plugins that operate on links and relationships to understand what the link is about. At first I also thought this is only of value for TiddlyMap but @ybabel and @tobibeer pointed out in felixhayashi/TW5-TiddlyMap#119 that it makes sense to have this in the core. Also @Jermolene wrote he is interested in adding a link qualifier (felixhayashi/TW5-TiddlyMap#119 (comment)). He mentioned that this link qualifiers may be used to influence navigation actions.

[felixhayashi]

I also don't think that for every turn we make we need to pick and chose and then implement some third party standard... unless someone clearly communicated very specific benefits of why and how to use any of those.

@tobibeer – SMW is quite popular and their syntax looks quite good, but I agree that it would break links for Tiddler titles containing ## (which I belief is highly rare though). So I am open for suggestions. Just saying: it should open [[ and close with ]] so parsing stays easy. But e.g. what you recommended back in felixhayashi/TW5-TiddlyMap#119 looked fine to me:

[[pretty-title|tiddler-title]](qualifier|qualifier|qualifier)

So I would not be against the above notation (although I am not sure if we should allow multiple qualitfies, but it may make sense, hard to tell…).

[tobibeer]

So I would not be against the above notation (although I am not sure if we should allow multiple qualitfies, but it may make sense, hard to tell…).

I'm not sure either but I can easily imagine two plugins having differing, if not conflicting needs... hence the idea of being quite explicit in a key-value sense. Not actually sure how to best design relations like that. In a TiddlyWiki sense, possibly the cleanest design would be to indeed just have a simple qualifier that actually exists as a tiddler ...giving details as to its nature and then showing any link-relations built on it, thus a query-interface to fetch qualified links.

[felixhayashi]

I'm not sure either but I can easily imagine two plugins having differing, if not conflicting needs... hence the idea of being quite explicit in a key-value sense.

Allowing a user to add a qualifier to give a link meaning doesn't need keys and any plugin should just use the information available. However, it is true that some plugins might distinguish their qualifiers. But then they should tell the user to use a prefix as part of the qualifier itself.

So, as said before, if a plugin really requires the user to distinguish the qualifier, then the plugin could tell the user "prefix all links that are meant for me with hallo+-" – but this is part of the property name and TiddlyWiki treats it as a normal qualifier. So if a plugin required a certain prefix, no problem, just give the qualifier a prefix but no need to enforce a key-value notation which makes the parsing rule even much more complex.

An example: In a Tiddler called Amy Jackson the text contains the phrase:

She received the pen as a gift
of her [[grandmother|Trudy Haminsworth]](ancestor of) and it
became very important to her.`

Now the user can install a bunch of plugins that understand and use this relationship Amy Jackson ancestor of Trudy Haminsworth. No need for key value pairs here as this qualifier expresses a universal truth. If some plugin named "TiddlyFooBar" comes along saying to the user "I only react to links prefixed with foobar+-123" then no problem, the user uses: [[grandmother|Trudy Haminsworth]](foobar+-ancestor of). So for TW the qualifier is foobar+-ancestor of and any plugin can decide whether and how to use this information. It is simpler than key value notation and gives plugins the chance to define their own prefixes and delimiters (if any are needed). In the end, plugins decide anyway which qualifiers they respond to, regardless of the notation chosen and key-value is not used in the world of semantic notation.

In a TiddlyWiki sense, possibly the cleanest design would be to indeed just have a simple qualifier that actually exists as a tiddler ...giving details as to its nature and then showing any link-relations built on it, thus a query-interface to fetch qualified links.

Well, this is plugin territory now. My proposal is just to add a qualifier. Then the next step, what to do with a qualifier, how to make sense out of it and how to create lists of links with the same qualifier, this is what plugins should do, and actually, this is what TiddlyMap does. Moreover, just like adding a tag doesn't force the user to create a tiddler of that title, a qualifier should not need to correspond to an actual tiddler.

---

In summary, I support @tobibeer's suggestion made in felixhayashi/TW5-TiddlyMap#119:
[[pretty-title|tiddler-title]](qualifier|qualifier|qualifier)

Fictive example:

[[grandmother|Trudy Haminsworth]](ancestor of|foobar+-goodfriend|bla::123)

• it allows multiple qualifiers
• is backwards compatible
• looks good
• only drawback: qualifiers are not allowed to contain a pipe symbol. So maybe we should use a delimeter consisting of two characters.

[ybabel]

[[grandmother|Trudy Haminsworth]](ancestor of|foobar+-goodfriend|bla::123) 👍

[tobibeer]

@felixhayashi, I think I'll concede that key-value specificity will possibly be overkill and possibly only complicate things by one degree too many. And yes, so long as the delimiters are clear, any plugin can always work with whichever suffixes or perhaps even separators it can handle.

[tobibeer]

only drawback: qualifiers are not allowed to contain a pipe symbol. So maybe we should use a delimeter consisting of two characters

I think we can always allow for an exception... and if truly ever needed perhaps also have an escape character, e.g. two pipes so as to say "this is supposed to be a pipe".

Here's one for key-value pairs:

[[Katherine]](ceo:tiddly-tech) wanted to go down a different route.

But sure, there may be plugins that know how to handle colons to formulate key value pairs.

[m42e]

Sorry for digging up such an old issue, but is something like this available by now?

[pmario]

I think the possibilities to implement a similar behaviour as discussed in the OP would be available once TW v5.3.0 will be available. So once we do have parametrized transclusions as described at: https://talk.tiddlywiki.org/t/parameterised-transclusion-introduction/4925

But I think a lot of water will go down a river, since we may get v5.2.4 in November and 5.3.0 will probably add several more months.

[Jermolene]

Thanks @m42e it's actually often interesting to revisit these old threads. I do still support the idea of attaching name/value pairs to links. These values would then be included in the tm-navigate message, the handler of which could process the name/value pairs as required. It would also be possible for message catchers to filter navigations based on these name/value pairs.

I have done a fair amount of work on investigating a more flexible navigation architecture in my work on https:// which I hope to bring into the core in due course.

So, I think the implementation of the requested feature is relatively straightforward apart from the question of the syntax.

One option that would be consistent with existing syntax would be to retrospectively declare that the [[title]] link syntax is actually a shortcut for [link[title]]. Then we can add attributes in the same way that we do for the similar [img[title]] syntax:

[link myproperty="Something" [target of link]]

[m42e]

@Jermolene Thanks a lot for all the efforts.

I would definitly like the syntax to be equal to the one used for [img] as it looks alike then.