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.

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.


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.


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