Thinking About Metadata

Some of my thoughts on tagging and metadata in Converspace:

• Syntax over Interface: I prefer (from a user experience perspective) how tagging (and other meta-data like mentions, etc.) evolved on Twitter to be just syntax and became part of the content (without being obtrusive) with no special interface elements dedicated to them. This allows for the same interface to serve people that don't need them, and the ones that do. Invisible to the users that don't need it but yet, always there for people that need it.
• Visible Metadata: My preference for tags being part of the content has the advantage of them being always visible (moves/hangs with the content). However, it also has the disadvantage of not being able to cleanly do things like private tags (like how Pinboard does with tags that start with a period. e.g., .secret_tag). One obvious advantage of private tags is that you can do stuff like what Selective Tweets does with the #fb tag, but without having a visible public tag: like this IFTTT receipe that crossposts Pinboard bookmarks to Twitter that have the .twitter private tag. For the specific use case of publishing workflows, I'm considering using (something I'm calling) local action tags (tags that start with &, e.g., &action_tag) that are ephemeral and consumed by the publishing workflow and not saved as part of the content. Action tags obviously cannot be interspersed with the content and will have to be added at the end. Still need to figure out how this will work when the publishing workflow is also adding machine tags at the end. 

Update (after sleeping over it): Won't be implementing actions tags (as described above) because of it's limited scope (especially when it comes to allowing third-parties to participate in the publishing workflow) and I'm on the fence about Machine/Triple tags.

Update (May 07, 2013):

• Auto-tagging: Allow for the publishing workflow to automatically add tags (including Machine/Triple tags). This is hard when you don't have a separate tags property and only have one blob of text (content). For example, it might not make sense to add tags at the end of single-line post when it is missing an ending punctuation mark. To allow for auto-tagging, I came up with a syntax for trailing tags. Trailing tags are preceded by a blank line, starts with two spaces, followed by space-separated tags, followed by the end-of-string. e.g., "\n\n  #additional_tag1 #additional_tag2". Trailing tags can be added at the end of content if they do not exist or tags can be appended to existing ones. I chose this syntax for the following reasons:
• When viewing the Markdown, trailing tags appear slightly indented, which visually separates them from the rest of the content.
• AFAIK, it doesn't conflict with existing Markdown syntax. This makes it invisible when rendered by processors that don't support it.

Update (June 05, 2013):

• Machine tags are invisible metadata: Machines tags provide context for "machines" and should be syndicated but not displayed.

See also:

• http://microsyntax.pbworks.com/w/page/20869409/Sightings
• Flickr: Discussing Machine tags in Flickr API
• http://pigsonthewing.wordpress.com/2008/07/04/triple-tags-on-twitter/
• http://microformats.org/wiki/microblogging-nanoformats
• http://www.pigsonthewing.org.uk/suggested-method-of-publishing-microformats-in-twitter-posts/
• http://microformats.org/wiki/picoformats
• http://twitterdata.org/
• http://blog.wolfspelz.de/2009/09/twitter-microtagging-personal-tags.html
• http://microsyntax.pbworks.com/w/page/20869401/Publishing