microformats
Designate u-watch-of as a proposed property
https://indieweb.org/watch
The property u-watch-of, is the visual companion to u-listen-of.
Publishers
- The WordPress Post Kinds plugin publishes watch posts using this property
- Using that, @chrisaldrich publishes https://boffosocko.com/kind/watch/ these posts on his site.
- @edwardhinkle posts them on his site.. https://eddiehinkle.com/watched/
- @gregorlove publishes it as a wants to watch https://gregorlove.com/2019/05/want-to-watch-take-back/
Consumers
- the Semantic Linkbacks plugin for WordPress consumes them.
Proposed definition
u-watch-of - indicates that this h-entry is a watch post...that you have watched a video (movie, TV, film), or a live show (theater, concert). The value can be a URL or an h-cite.
Noting some issues and background on this.
- @gRegorLove used it as an aspirational property(Wants to Watch), whereas all other usages are passive(Watched).
- @cleverdevil posts https://cleverdevil.io/2019/avengers-endgame-2019, which are not marked up using this property, and are fed from Trakt.
Trakt is a scrobbling service for movies and TV and has an API. @grantcodes apparently used to do this, but it isn't online at the moment.
Possible questions include:
- Like audio scrobbles, should the value be h-cite or url only? Or, as @cleverdevil does, an h-item or h-review?
- How do you indicate status of completion? See https://github.com/microformats/h-entry/issues/10 where read-status was discussed for the same issue with read posts. We should use a property that carries to all of these types.
Yep, although my automatic posting tool is currently offline, the code is on GitHub and I have created many watch posts with it.
I don't use special properties apart from watch-of which is set to the episode / movie url on trakt.tv - I also pass a special trackt property with all the data from the api, which is probably bad practice :P
I would say the content of the u-watch-of should probably only ever be a url orh-cite. Reviews could be in the content of your post or the content of the cite.
I don't think it makes sense to have a different property for a listen status, read status & watch status. If they all shared the same property with values like future, in-progress & complete (for example) that would probably cover all use cases. EDIT: Oops didn't realise this was already a separate issue: #18
