Discussion of Status for Proposed Properties watch, read, and listen

[dshanske]

See #10 #11 #17

These all have in common the issue of wanting to report whether you have listened, will listen, and possibly whether it is in progress.

This issue is to track discussion and brainstorm on a common way to do so.

A few possibilities

• An actual status property. For example, status is a property referenced in hcalendar, but didn't make the jump to h-event.
• You could use dt-start and dt-end to indicate the start and end dates for when you began or completed something. But what then indicates not yet started? Can you have an empty start or end date?
• If you used start and end, and also had a published/update property, how would that be interpreted?
• Use a category property...the problem on this is consumption. How do you handle the shared vocabulary? Categories don't have any.

[jgmac1106]

p-x-want
p-x-started
p-x-in-progress
p-x-finished

To me those are the four states for media, the final property for me doesn't matter as much as long as we can express these four states.

If doing this with p-category and you wanted to solve consumption can you do with a data class?
<data class="p-category" value="want">Want to</data>

[dshanske]

Category is not designed that way though currently

[jgmac1106]

Yes it is not, but if you wanted to build a view in Wordpress you could either use the value of the data class or maybe have a function that does something like "if a read post...and then transform the first p-category into a variable to use.

Don't want to confuse consuming and parsing so if my ideas are totally off please let me know.

[dshanske]

I am waiting for more comments. To me personally, overloading category is confusing.

[jalcine]

This is something I’ve punted on for some time until I had proper tooling to incorporate it to my site. For now, I want to expose what song I’ve recently listened to on my site - which wouldn’t be hard to do if I use likes to handle it. But it doesnt allow for me to provide more semantically useful information about a song (the composer, album art and even the year of the form I’ve listened to). The markup I wanted to go with was an overloading of p-audio but with the u-url marked as a rel=alternate instead of a vanilla link. From what I read, that seems like the cleanest way to show that this is audio (a song) I’ve consumed (if I put it in a h-cite > p-audio) and had some kind of interaction with it.

(Originally published at: https://v2.jacky.wtf/post/e6d1923c-767b-48d4-b2f0-704fb2451e42)

[dshanske]

@jalcine This is about status of a listen/watch/read post. You want #11 for comments on the listen property

[gRegorLove]

Have we documented the real-world use-case for the problems the potential property/properties solve? What's the use-case for both publishers and consumers?

I think the consuming use-cases are important to clarify and will help guide the discussion.

Edit: I think to keep the proposal conservative we should focus on the "status" discussion, not necessarily any start/end date options.

[dshanske]

Use case. I consume media. Either I want to...in which case this is part of an aspirational post, or I want to note my progress.

[dshanske]

For me, I had originally only considered these properties to be post consumption. But I see why someone might want to track their place in something, or note future desires.

[dshanske]

There is a question of whether status is the best way to create a to read/watch/listen list.

[jgmac1106]

@dshanske why not an h-entry with an h-event for when a media was started and/or finished. Wouldn't need anymore properties and it fits all the hypothetical situations.

This way @jalcine could track his songs but the dt-published doesn't have to match the date of the event.

[dshanske]

Why use the h-event? You can just have dt-start and dt-end?

[jgmac1106]

yeah that makes sense as well.

…

On Wed, Jul 17, 2019 at 7:09 AM David Shanske ***@***.***> wrote: Why use the h-event? You can just have dt-start and dt-end? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18?email_source=notifications&email_token=ACQL5JQ7UHNE647DS2RSM6TP734X3A5CNFSM4H3N5GUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2D3D6A#issuecomment-512209400>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACQL5JSULBDCOJ4U7R4PQSTP734X3ANCNFSM4H3N5GUA> .

-- J. Gregory McVerry, PhD Assistant Professor Southern Connecticut State University twitter: jgmac1106

[dshanske]

At HWC West Coast 2020-05-06, proposed to use inspiration from the HTML progress element and the iCal TODO status elements as prior art.

Progress element allows for properties max and a value.

iCal TODO status elements include: https://tools.ietf.org/html/rfc5545#page-93

• "NEEDS-ACTION" ;Indicates to-do needs action.
• "COMPLETED" ;Indicates to-do completed.
• "IN-PROCESS" ;Indicates to-do in process of.
• "CANCELLED" ;Indicates to-do was cancelled.