Designate u-watch-of as a proposed property

[dshanske]

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.

[dshanske]

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 u-read-of/read-status proposed draft #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.

[grantcodes]

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

[jgmac1106]

Agree @grantcodes a progress status that can work for any media type.