#microformats 2023-11-03

2023-11-03 UTC
gRegorLove_ and gRegorLove__ joined the channel
#
[tantek] [fluffy] a lot of time went into classic mf1 hAudio and later hMedia but it kinda fizzled out
[Murray] and [KevinMarks] joined the channel
#
[KevinMarks] I know music metadata has been through a few iterations recently, with Apple making a classical music specific player for example. Are you seeing uptake for more specific fields than the old mp3 ones? It may be worth another try at mapping and converging the existing ones in use at least.
ancarda joined the channel
#
GWG I know I did some speculative notes somewhere on media markup
[snarfed] joined the channel
#
[snarfed] https://indieweb.org/audio , https://indieweb.org/duration , https://indieweb.org/media_fragment
#
[tantek] hAudio was for tracks, take a look at the work that went into it. A bit more generally hMedia could have been used for albums, tracks, etc.
#
[tantek] its development was quite contentious so I'm not saying it's the end all be all, I'm saying a lot of labor went into it, and presumably at least some of that is re-usable
#
[tantek] we've talked about possibly creating an h-media for mf2, but if we did, I think we should be careful to design to work as a complementary extension to h-entry, not as a "rich media h-entry"
#
[tantek] that is I could see have an h-entry with a "u-enclosure h-media" and have that h-media have more details about the media item in particular
#
[tantek] but NOT duplicate the properties in the h-entry
#
[tantek] that's for the "obvious" IndieWeb / podcasting use-case
#
[tantek] if I was going to re-explore this today, I'd (re)start at https://microformats.org/wiki/media-info and create a "media-info-use-cases" page to first document what the user flow scenarios are that we'd want to support/enable (e.g. podcasting, sharing media playlists, etc.)
#
sknebel I seem to remember some discussions from a Berlin IWC that went in a similar direction
#
sknebel have a microformat that can be used in a u- property, many consumers can just take the url value and ignore the rest, if something wants more data it can get it there
#
[tantek] precisely
#
[tantek] I think that's the best way to create a simple and fairly minimal design that can be used to mark-up the information that people are already publishing
[timothy_chambe] and [schmarty] joined the channel
#
[schmarty] excited about this discussion! one thing i personally would love support for is "media alternatives" or whatever the appropriate term is. subtitle and caption tracks for video, multi-lingual audio tracks and audio description tracks, and maybe even ways to denote things like "this mp3 is an audio-only alternative to this video".
#
GWG [tantek]: That was the speculation I think I made.
gRegorLove_ and neceve joined the channel
#
[tantek] [schmarty] for "media alternatives", I think it would be useful to document existing publishing practices of that using the HTML audio element and multiple source elements etc
#
[schmarty] yep. i don't think i've contributed like that in the past on the mf wiki. maybe i can start it as a blog post?
[nsmsn] and m5zs7k joined the channel
#
[tantek] you can always start something as a blog post, then the wiki can cite that!
#
[tantek] blogpost++
#
Loqi blogpost has 1 karma in this channel over the last year (2 in all channels)
#
[KevinMarks] Is there better structured data on bandcamp than on the streaming silos? I know this is a very long running contentious space, with musicbrainz and cddb as the previous open vs clsed examples, but i don't know how it has changed in the last decade or so
gRegor and IWSlackGateway joined the channel
#
f​luffy.critter reposting what I wrote on slack so it actually appears to others
#
f​luffy.critter original posts:
#
f​luffy.critter Has anyone put any amount of thought into mf2 markup for music stuff? I wrote a new accessibility-focused embeddable music player (https://github.com/fluffy-critter/camptown) and I’d love to add microformats to it, but there’s not a lot of ideas beyond vague handwaving on the wiki.
#
IWDiscord <f​luffy.critter#0>
#
IWDiscord <f​luffy.critter#0>
#
f​luffy.critter yeah I remember the old del.icio.us playtagger (which later became the Yahoo! media player) used h-track as a signal to the player for which things should get a play button. At the time I didn’t realize that was a microformat.
#
f​luffy.critter 8:50
#
f​luffy.critter Music albums are different than podcasts/audio blog posts, though.
#
f​luffy.critter 8:51
#
f​luffy.critter I’m thinking h-album for the album as a whole, h-track for the individual tracks, and h-card for the artist information. Is that plausible? And then attributes like p-duration and p-title and so on.
#
f​luffy.critter 8:52
#
f​luffy.critter My player also supports lyrics (which I suppose would be p-lyrics ) and extended information including markup (so e-content or something)
#
f​luffy.critter 8:54
#
f​luffy.critter h-album might be too generic though, like, the word “album” could also refer to a photo album
#
Loqi [preview] [fluffy-critter] camptown: A simple Bandcamp-style embeddable music player
#
f​luffy.critter and in response to Kevinmarks:
#
f​luffy.critter there are userscripts that people use to basically screenscrape bandcamp to import data into musicbrainz
#
f​luffy.critter bandcamp provides no structured data 😕
#
f​luffy.critter My concern with using h-entry to represent an album is that a music album is a fundamentally different thing from a blog post/article.
#
f​luffy.critter Like you can write a post about an album but the album itself is its own unit of data. Maybe I’m misunderstanding the genericity of h-entry though.
#
f​luffy.critter also I’m not sure how u-enclosure would work for this case? Like, the album as a whole is what’s being enclosed, but it’s comprised by a bunch of separate audio files, but the audio files themselves have a bunch of structured data as well.
#
f​luffy.critter I guess my question is: what should be the top-level container for the album as a whole, and what should be the container for each track?
_fluffy, gRegor, [tantek] and neceve joined the channel
#
_fluffy Okay so now that I have IRC stuff sorted out, I'd still like to figure out the right way to deal with mf2 on a music album. What would be the correct h-* type for the album as a whole, and for each track? I think the rest of it follows pretty obviously.
#
_fluffy Here's an example album (without any iframes/embeds), if that helps any: https://cdn.sockpuppet.us/refactor/
#
_fluffy Like, is there some appropriate nesting structure for providing separate but related content items within an h-entry?
#
_fluffy like would it be appropriate to do h-entry for the album and h-item (with u-enclosure) for tracks within the album?
#
_fluffy Also given that the player is typically embedded via an <iframe>, what are the implications on that regarding microformat parsers?
#
gRegor Think iframe will be ignored, unless it has a u-* with a src, then that src URL will be parsed
#
gRegor For nesting, some similar previous work is marking up comments inside the h-entry with `u-comment h-cite`
#
gRegor So maybe u-track h-item in this case
#
[tantek] gRegor is right, the iframe is a separate URL. so if you send that URL to a parser it'll see the stuff inside
#
[tantek] Which begs the larger question, what is the motivating practical consuming code use-case for marking up a music album? Without that, it's not worth extra effort to mark up a music album?
#
gRegor Not a direct use-case, but I could see it being useful to plug into a translator like Granary, microformats -> XSPF playlist https://www.xspf.org/. Apparently they have JSON JSPF now, even.
#
gRegor Not too familiar with those playlist formats or support, worth checking as prior work though