Semanticmediawiki: #HashTag annotation support

[mwjames]

Setup and configuration

• SMW version: all

Feature

Semantic MediaWiki serves different user groups, some of them may seek a #hashTag [0] support to simplify the annotation process such as adding keywords (see #3020) to a text without having to remember a specific property, yet want be able to query those tags using the standard SMW infrastructure and query interface.

It is proposed to use $smwgHashTagProperty as setting (by default disabled) that defines the global property to be used whenever a #... annotation appears and is turned into a SMW annotate value. Given that the Keyword type normalizes any upper/lower casing it provides best type and allows for additional match agility without requiring users to manually transform those tags (e.g. #FOO == #foo == #FoO).

Example

Notes

"...# (also known as the hash character) in front of a string of alphanumeric characters, usually a word or unspaced phrase, in or at the end of a message. The hashtag may contain letters, digits, and underscores. " [0]

[0] https://en.wikipedia.org/wiki/Hashtag

[kghbln]

This is a good idea and will be a cool feature. However using the pound here may confuse users since wiki links within a page are also using the pound and render identically. Thus SMW needs somehow to adapt the user facing display to make sure that both cannot be confused.

[mwjames]

the pound here may confuse users since wiki

# is the recognized character for a hash tag, not sure about using a different identifier since that would no longer be hash tag.

SMW needs somehow to adapt the user facing display to make sure that both cannot be confused.

I'm not sure I understand what you mean by "adapt the user facing display".

[kghbln]

.. is the recognized character for a hash tag, not sure about using a different identifier since that would no longer be hash tag.

Indeed. That's why I figure that the "user facing display" of the link should be adapted.

I'm not sure I understand what you mean by "adapt the user facing display".

If you just see something like #Notes you will not be able to see if it is a hash-tag annotation or an intra-page link. Currently I have no decisive idea how it could look like, perhaps #::Note for the annotation or something like it.

[mwjames]

that the "user facing display" of the link should be adapted

Links in the above example only appear because I added a Formatter schema to the Has keyword, under normal circumstances it will be just a plain text (unless of course you add a formatter).

[kghbln]

Lets ask like this: Will the link created link to a page of that name? In this case the pound does not need to be rendered at all. However even if it links to a query for the respective pages with that keyword the pound does not need to be rendered either. I guess this would follow the same scheme as in-text annotations and in the end this is only a variant of it anyways.

[kghbln]

Links in the above example only appear because I added a Formatter schema to the Has keyword, under normal circumstances it will be just a plain text (unless of course you add a formatter).

Ah, ok, I am with you! Cool!

[mwjames]

it links to a query for the respective pages with that keyword the pound does not need to be rendered either.

We store the tag without the hash symbol, so any query will look like [[Has keyword::test]] for a #test tag.

[s7eph4n]

I like the feature. I wonder though if it should be part of core SMW.

[mwjames]

I like the feature. I wonder though if it should be part of core SMW.

Well, the code itself (without tests) is roughly as seen and would be part of the InTextAnnotationParser.

+       // Process `#...` tags
+       if ( $this->hashTagProperty && $this->hashTagProperty !== '' ) {
+           // Twitter regex (include underscore and not start with a number):
+           // (?<=^|\P{L})(#\b\p{L}[\p{L}\d_]+)
+
+           // Allow to start with a number
+           $text = preg_replace_callback(
+               '/(?<!&|\S)#(\w+)/u',
+               function( $matches ) {
+                   return $this->addPropertyValue(
+                       [ $this->hashTagProperty ],
+                       $matches[1],
+                       $matches[0]
+                   );
+               },
+               $text
+           );
+       }

If you wanted to move this to an extension then we would need to add a hook to InTextAnnotationParser and make the addPropertyValue public (otherwise you have to rewrite that part for the extension).

[s7eph4n]

It just seems to me that from a high-level perspective this feature would be a candidate for a separate extension. I don't know enough about that class to have an opinion on whether it is worth the effort to break it out or not, so whatever you decide is fine with me.

(Having this hook would also open up the possibility of similar extensions where an attribute is set by annotations other than the classic [[foo::bar]]. Will that ever be used, though?)

[jaideraf]

This feature used with tagcloud format from SRF is going to be awsome!

[jaideraf]

@mwjames I am curious about this Formatter schema. It would be possible to link to "a query for the respective pages with that keyword", as @kghbln said? I mean, when clicking on a hashtag, we could see a "normal" page with a query to that keyword (sending via $1 or somenthing like that)? Or a special page like Ask ou Browse? Or this Formatter schema is not about setting that type of behaviour?

[jaideraf]

I am sorry, I have just read about the Formatter rule now. The text answers my questions above: it links to special pages Ask or SearchByProperty.

[mwjames]

It just seems to me that from a high-level perspective this feature would be a candidate for a separate extension.

Okay, I decided that we will go with a hook (#4169) that can be registered and contain a HashTagPasrer as demonstrated in [0].

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/docs/examples/hook.parser.afterlinksprocessingcomplete.md

[JeroenDeDauw]

Just reading this now and was going to suggest to only create an extension mechanism if there is an additional use case. I'm great at timing right?

I don't see an issue with having the hook though recommend not spending time on putting this in an extension since there is likely many better things to do with ones time.

[kghbln]

Okay, I decided that we will go with a hook (#4169) that can be registered and contain a HashTagPasrer as demonstrated in [0].

Ok, so this will be a dedicated extension when implemented.

I don't see an issue with having the hook though recommend not spending time on putting this in an extension since there is likely many better things to do with ones time.

This appears to be something for starters to implement.

[mwjames]

>

This appears to be something for starters to implement.

For some inspiration, see [0].

https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/docs/examples/hook.parser.afterlinksprocessingcomplete.md

On 8/21/19, Karsten Hoffmeyer [e-mail] wrote:

Okay, I decided that we will go with a hook (#4169) that can be registered
and contain a HashTagPasrer as demonstrated in [0].

Ok, so this will be a dedicated extension when implemented.

I don't see an issue with having the hook though recommend not spending
time on putting this in an extension since there is likely many better
things to do with ones time.

This appears to be something for starters to implement.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/3651#issuecomment-523467788