Hugh @hugh@ausglam.space

@saera I'm extrapolating from the last VALA email. I haven't actually seen the survey results.

TFW the conference highlight for one participant was the opening address by a sponsor.

@kassi_grace 🤞🏻

@alissa UPDATE

Just did this with four lines of code, and one of those was a closing curly-brace.

It does interesting (aka unexpected) things to the order in which other tags are chosen, but that's for another day to investigate.

I'd temporarily forgotten how cool npm is while I was noodling around with Python and Bash.

I'm not going to link to the article because it's terrible and full of bad jokes at the expense of a particular programming language, but I did LOL at this:

"This doesn’t scale, and everyone wants to scale. According to every [software] architect I’ve ever sat in a meeting with, “scaling” is more important than the application even working."

@saera I did INELI with someone whose name was literally ‘Ra’.

@kassi_grace any progress?

Daytime drinking amirite.

...

@alissa ah, I see what you're saying. So rather than normalising everything, only be concerned about the couple of tags likely to be of interest that come in certain non-standard but predictable variations. In that case it might actually be simpler to continue to do it on the way 'out' rather than on ingest.

I'll have to see how much that slows down loading the home page though, because I'd have to run every tag through a comparison function.

@alissa I'm not *necessarily* averse to creating a normalised tags field (in addition to the original tags).

This would be simpler and more computationally efficient than trying to merge them on the fly.

BUT ...I'm not sure I want to do that. Librarian Hugh wants an Authority FIle. GLAM Hugh wants to Respect des Fonds. Coder Hugh kind of wants it both ways - which raises complicated questions like whether to display original or normalised tag names for a normalised search.

@alissa Correct. It's sort of the inverse of a controlled vocabulary. I'm doing it this way for a couple of reasons, but it's also interesting to think about how managing this computationally is different to classic info management assumptions. Probably will blog about it for Transform.

@alissa To clarify: the tag 'cloud' links will collect any broadening of the search just like other tags, but what I meant is that if tags were merged prior to calculating which ones are 'most popular' the accounting could change. e.g. if 'blog june' is used 8 times and 'blogjune' is used 4 times then I'd rather merge them to one tag with a value of 12.

@alissa I'm literally writing that at the moment - I'm going to try to do documentation on how things work immediately following writing the code - as much for future me as anything else.

@alissa better?

@alissa I'd really like to 'normalise' the top tags list in some way so that e.g. 'glamblogclub' and 'glam blog club' are merged, including their total usage numbers, for a more accurate list. But I can't work out how to practically do that.

@alissa oh, nice one, author names were accidentally left off - done! (though, blog titles and author names are whatever they were at the time the article was published).

Re the top tags, I initially had a header saying 'top tags' but I like it better without the heading. Thoughts welcome. It's the 10 most-used tags from the last 60 days. Either of those numbers can easily be adjusted (by me I mean, not by end users).