Suggestion: Option to merge URI and label in one column

[jneubert]

I like the preflabel.org approach to provide labels for "naked" URIs. However, within a certain dataset, you often have labels handy, even within the same request in a seperate column. See for example the results of

http://zbw.eu/beta/sparql-lab/?queryRef=https://api.github.com/repos/jneubert/skos-history/contents/sparql/stw/moved_labels.rq

It would be really useful if the uri und label columns could be merged basicly as

<a href="{uri}">{label}</a>

A possible way to associate a certain label with a certain colum could be a naming convention, such as ?YASLabel4oldConcept is related to the URI in ?oldConcept. This may look not overly elegant, but it should work without theatening side effects, and could be triggered by some setting for the table object - and the practical value would be really large.

[LaurensRietveld]

That's an interesting approach. I probably won't implement this as a basic feature of YASR though: I'd like to do as little preprocessing as possible of the values I show, as this tool will mostly be used by developers. Making this configurable is an option, but something I'd like to avoid for the YASR library to keep the functionality and interface as clean as possible. Perhaps in the YASGUI rewrite, where we focus more on the UI side, we could support toggling this behaviour.

But I was looking for some YASR gists to make, and this is a nice one. (as implementing this requires overwriting one function) So I'll let you know when I've made something

[LaurensRietveld]

Now I think of it: it should be easy enough as well to make the cell text show the URI on hover, and the label otherwise (to make it a bit more explicit that we are dealing with a URI here). I'll generate the gist, and we can see on how to proceed from there

[jneubert]

Yes - the hover solution sounds perfect, as the label may be the same for two different URIs.

[LaurensRietveld]

See here for a gist I added: http://bl.ocks.org/LaurensRietveld/raw/7d4ccee95a0d45e95865/

[jneubert]

That's it - exactly!

As you put it in the Gist, it is beautifully simple and straightforward, and easy to copy into custom code. Yet, since may be useful in many situations and for many users, I'd consider to make it an option within YASR. It could make the library itself even more fancy :)

[LaurensRietveld]

I'm still a bit hesitant. Mainly for the UI part:

• Hovering increases or decreases the size of a cell drastically, making the table go up, down, left and right whenever you change the pointer between cells. This is particularly annoying with many rows and columns in the table (don't know whether this is a performance hit though. Havent tested it on a table with a size of e.g. 500x10.
• This would be a toggeable (i.e. checkbox) feature. How would you name it, without the need for a user to check the documentation? (preferable as simple a name as 'filter' and 'search'). I'd like to limit the options presented to the user to avoid too much clutter, and I'd like the options to be at least self-explanatory.

gr Laurens

On Thu, Nov 20, 2014 at 8:54 AM, Joachim Neubert notifications@github.com wrote:

That's it - exactly!

As you put it in the Gist, it is beautifully simple and straightforward, and easy to copy into custom code. Yet, since may be useful in many situations and for many users, I'd consider to make it an option within YASR. It could make the library itself even more fancy :)

— Reply to this email directly or view it on GitHub https://github.com/YASGUI/YASR/issues/14#issuecomment-63772434.

[jneubert]

Hi Laurens,

to start with your second concern: In my eyes, this could be controlled by the developer working with the library by activating an option which is not set by default - not by the end user, which normally would have difficulties to comprehend what's going on. For the developer, the name of such on option could be mergeUrisWithLabels. The developer is in control on two levels: If she doesn't activate the option, nothing happens. And she develops the query as well, via slight variations of variable names she can control if a merge takes place for a certain uri/label pair - or not. The only perhaps problematic situation is when application and query developers are two different persons,and the latter uses a ?{uri}/ ?{uri}Label variable name pair just by accident. The effect would be surprising. Hopefully it would be conceived as a feature on second sight. It could be avoided by some elaborated naming convention (like YASLabel4{uri}), which would not be hit by accident - but this makes the "plain" query looking a bit weired.

On your first concern: I didn't realize this. Perhaps then it would be better to use title attribute which shows <{uri}> or even Resource: <{uri}> on hover.

Just my 2c - Joachim

[LaurensRietveld]

Yes, I can live with that. I'll see what I can do on integrating this properly

On Thu, Nov 20, 2014 at 12:01 PM, Joachim Neubert notifications@github.com wrote:

Hi Laurens,

to start with your second concern: In my eyes, this could be controlled by the developer working with the library by activating an option which is not set by default - not by the end user, which normally would have difficulties to comprehend what's going on. For the developer, the name of such on option could be mergeUrisWithLabels. The developer is in control on two levels: If she doesn't activate the option, nothing happens. And she develops the query as well, via slight variations of variable names she can control if a merge takes place for a certain uri/label pair - or not. The only perhaps problematic situation is when application and query developers are two different persons,and the latter uses a ?{uri}/ ?{uri}Label variable name pair just by accident. The effect would be surprising. Hopefully it would be conceived as a feature on second sight. It could be avoided by some elaborated naming convention (like YASLabel4{uri}), which would not b e hit by accident - but this makes the "plain" query looking a bit weired.

On your first concern: I didn't realize this. Perhaps then it would be better to use title attribute which shows <{uri}> or even Resource: <{uri}> on hover.

Just my 2c - Joachim

— Reply to this email directly or view it on GitHub https://github.com/YASGUI/YASR/issues/14#issuecomment-63792463.

[LaurensRietveld]

Hi Joachim, You can now find this option in the new version of YASR