discovery (5 out of 5)

What is this, new Captain every episode..?

Enjoyed the red herring.

Jett Reno is awesome can she stay?!

🏷 star trek discovery

Sat 19th of January 2019 at 6:42pm (+02:00)

(Star Trek Discovery)

That was a really good episode. We were due a kooky time loop one of course to match previous series.

Ugh Mudd though. When he said "that won't be last you see of.." I was hoping he was addressing the audience not the crew, and meant his ToS episode.

🏷 star trek discovery

Mon 30th of October 2017 at 10:33pm (+01:00)

The REAL mystery is: how does captain dangerman mcwhitedude keep a consistent population of ONE tribble on his desk??

🏷 star trek discovery

Tue 3rd of October 2017 at 12:12am (+02:00)

Klingon fashions and hairstyles sure changed over a couple of centuries. I love their (the Klingons') diversity though.

I'm disappointed by the lack of space in the opening sequence. Never enough space.

I anticipate great lolz from Saru.

But yeah, I think we're off to a good start.

🏷 star trek discovery

Mon 25th of September 2017 at 11:33pm (+02:00)

Post type discovery

Several months ago I wrote about switching from explicit to implict post types for my blog, and looked a little at generating an ActivityStream from content objects (posts) based on their properties. My thoughts have progressed on both of these things since then, and I've also added a few more post types to my site. Yesterday Tantek published a working draft of a post type discovery algorithm so to add to the discussion, here is the version of this that I currently implement; similar but different.

I mostly use this to display different icons by posts. Worth noting that I don't in anyway differentiate photo type posts, just notes or articles with photos embedded in them, sometimes with properties that make them display as more specific types (like a checkin). Speaking of, I've previously written my quite specific handling of checkins vs notes with location.

• if content

  • note post

• if header (aka title aka name)

  • article post

• if startLocation and endLocation

  • travel plan post

• if reply-to

  • if rvsp
  • • rsvp post
  • else
  • • reply post

• if location

  • checkin post
• if like-of
  • like post
• else if repost-of
  • repost post
• else if bookmark-of
  • bookmark post

• else if follow-of

  • follow post

• else if type(LlogPost)

  • llog post
  • if food tag
  • • food post
  • if sleep tag
  • • sleep post
  • if exercise tag
  • • exercise post

• if read-of

  • read post

• if mention-of

  • // I use this when I'm displaying incoming webmentions that don't pick up another type, I don't have any of my own posts I consider 'mentions' posts yet
  • mention/link post
• if location and not content
  • vague checkin

My algorithm cascades; ie. the last criterion that matches takes effect.

However, I don't display different posts very differently... in fact, I use one template for everything, and for all posts with content, display all properties which are present. So all posts with additional properties might as well also be considered notes and articles.

Issues

In just writing this out I've noticed a few things I need to tighten up. For example, I see no reason a like post can't also be a bookmark and a repost (you might disagree..) so I will tweak to allow that, and make decisions about how to display that. Vague checkins need to check for latitude and longitude properties.

LlogPosts (lifelog aka metrics) still have an explicit type, as they're otherwise just notes with specific tags. Currently this is the easiest way to filter them out of a list, as I don't want to display them in my main feed. At some point I will enhance the display of these from just text, and I'll need to alter how these are identified to do that.

Querying

For my implementation it's a huge pain to exclude posts from a list based on their properties, but this is because I'm stuck on SPARQL 1.0. Plumbing.. So I won't labour that. It does seem instinctively easier to query posts based on explicit types, so I'm still not sure if I won't actually start storing these again anyway, when the post is created.

On the other hand, why is that any easier than querying based on properties? Seems like preferences would be dependant on programming and query languages, so maybe neither way is clearly better. Adapting a UI based on the properties present may allow more flexibility in display, in the end. I'll be playing around some more, anyway, and in particular adding in some more activity-like posts fairly soon.

Additionally, when I start sorting my different feeds out, some by 'type' and some containing a mixture of 'types', this could get more interesting.

🏷 algorithm discovery explicit typing implicit typing indieweb indiewebcamp post types social web socialwg

Wed 30th of September 2015 at 5:31pm (+01:00)