Semanticmediawiki: New extension: LinkSummaryCard (hover facts over links)

[mwjames]

[0] is known to provide an extension that produces a hovercard on links but somehow it didn't solve the problem I wanted to solve.

Since the name Hovercards is already in use, I'm looking for a new extension name:

• FactsCard
• LinkFactsCard
• Linkcard
• DiscoveryCard
• LinkSummaryCard
• SummaryHighlighter

LinkSummaryCard makes use of the existing infrastructure (deployed by SMW), reusing the qtip tooltip as basis for the display.

Why

For those who are lazy (probably only me) it may help to avoid having to screen each link embedded in a page. LinkSummaryCard can provide a short cut to show a semantic summary of what a subject is about by just hovering over a legitimate link.

What

Functionality of LinkSummaryCard is limited to:

• Find all href links and validate whether it is a legitimate link for LinkSummaryCard or not
• Build the template content
• Request a template parse via the MW API
• Add the response from the MW API to the qTip tooltip
• Support client-side caching to ease API requests
• Support for custom templates which are to be specified per namespace to allow for a more fain grained display and collection of rules that define a semantic summary
• User can disable the card

How

The qTip tooltip is used in SMW, SemanticGlossary, and SemanticCite (though uses a different style).

After recycling JS code from SemanticCite and WhatsNearby, LinkSummaryCard uses a similar feature set with templates being used to define form and content on a subject that is requested via Ajax.

LinkSummaryCard itself doesn't do any specific querying and instead relies on parsed templates to gather the information one wants to display.

$GLOBALS['shcgEnabledNamespaceWithTemplate'] = array(
    NS_MAIN         => 'Hovercard',
    NS_HELP         => 'Hovercard-Help',
    NS_FILE         => 'Hovercard-File',
    SMW_NS_PROPERTY => 'Hovercard-Property',
);

A template that contains:

<includeonly>{{#ifeq: {{{isFile}}} | true | [[{{{subject}}}|250px]] }}
<div style="font-size:small;line-height: 100%; min-width: 250px;  max-width: 250px;"><p>Subject: {{{subject}}}</p>
<p><span style="word-wrap: break-word;  word-break: break-word;">{{#show: {{{subject}}} |?Has description}}</span></p>
{{#ifeq: {{{isProperty}}} | true |<p>Type: <span style="word-wrap: break-word;  word-break: break-word;">{{#show: {{{subject}}} |?Has type}}</span></p>}}
<p>User language: <span style="word-wrap: break-word;  word-break: break-word;">{{{language}}}</span></p>
<p>Namespace: <span style="word-wrap: break-word;  word-break: break-word;">{{{namespace}}}</span></p>
<p>isCategory: <span style="word-wrap: break-word;  word-break: break-word;">{{{isCategory}}}</span></p>
<p>isFile: <span style="word-wrap: break-word;  word-break: break-word;">{{{isFile}}}</span></p><div></includeonly>

will output something like:

[0] https://www.mediawiki.org/wiki/Beta_Features/Hovercards

[mwjames]

@kghbln @JeroenDeDauw Any preference for a name?

[kghbln]

Wow, another upcoming goodie! In case SMW is required probably one of these two:

1. SemanticLinkCard
2. SemanticHoverCard

or if it may run standalone:

• LinkCard

I have a preference for Link so SLC or LC are my favourites.

[JeroenDeDauw]

Name: SummaryCards, HoverSummaries (I think it makes sense for the name to be plural)

I'm not sure about the Semantic prefix. It's whats done so far, and from a technical standpoint the dependency is important. However for users it might not be as important, and advertising wise IDK. Some people have been saying the word Semantic is not good, and certainly some people will simply not look at the extension if it has that in the name even if its useful for them. Just some thoughts, I have no strong opinion either way.

[JeroenDeDauw]

Cool extension idea. May I suggest to require PHP 5.5 and MW 1.23 right off the bat?

[kghbln]

Name: SummaryCards

Either plural or not. I quite like this suggestion. Not sure why I ignored this in James' set of suggestions. Running up is LinkCard(s).

Some people have been saying the word Semantic is not good, and certainly some people will simply not look at the extension if it has that in the name even if its useful for them.

Well there are people who already have this feeling at the wiki level. Without further words ...

[JeroenDeDauw]

Well there are people who already have this feeling at the wiki level.

[mwjames]

Done with https://github.com/SemanticMediaWiki/SummaryCards

[mwjames]

@kghbln If time permits, having mediawiki/summary-cards:@dev available on the sandbox would be neat.

My local test settings are

$GLOBALS['sucgBackendParserCacheType'] = 'redis';

$GLOBALS['sucgEnabledNamespaceWithTemplate'] = array(
    NS_MAIN         => 'SimpleSummaryCard',
    NS_HELP         => 'SimpleSummaryCard',
    NS_FILE         => 'SimpleSummaryCard',
    SMW_NS_PROPERTY => 'SimpleSummaryCard',
);

Default settings can be found at [1].

[0] https://packagist.org/packages/mediawiki/summary-cards
[1] https://github.com/SemanticMediaWiki/SummaryCards/blob/master/SummaryCards.php#L97-L133

[kghbln]

Done, though I have used CACHE_MEMCACHED instead. So far I did not have the time to switch the wiki to redis. I believe you may only have one or the other though redis makes increasingly more sense since not only semantic extension prefer this one.

[kghbln]

Got this

PHP Notice:  Use of undefined constant SMW_NS_PROPERTY - assumed 'SMW_NS_PROPERTY' in /.../w/LocalSettings.php on line 559

so I now moved the configuration below the one for SMW. I guess this should fix the issue and probably be noted somewhere in the README.

[mwjames]

so I now moved the configuration below the one for SMW. I guess this should fix the issue and probably be noted somewhere in the README.

The extension doesn't require SMW but in case it referenced (as for the NS) setting should be after the enabledSemantics.

[kghbln]

The extension doesn't require SMW but in case it referenced (as for the NS) setting should be after the enabledSemantics.

Yeah, that's what I meant. Thanks for confirming.

[mwjames]

though I have used CACHE_MEMCACHED instead. So far I did not have the time to switch the wiki to redis

For the technical and resource minded people out there, since the standard MW ApiParse didn't allow to cache generated results in away it is practical, SummaryCards API backend module does the job as designed for the extension.

The difference between doing a parse for an API request or getting it from cache can be found as meta data on each request.

If a subject or the template that generates the content gets altered then the backend cache is evicted, in all other cases users browsing the same link will get if available, cached data to avoid having the server run wild or being flooded with #ask queries from the template.