mf2 (5 out of 5)

Social Web WG 4th face-to-face summary

This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!

See also day 1 minutes and day 2 minutes.

What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome.

tl;dr

Most AS2 issues are closed! CR-blocking issues are now due by 15th December.
We took a bunch of things to Editor's Draft and are pushing for FPWDs as soon as is viable.
Some of the drafts overlap but there's a general feeling that since there are keen editors we should work on everything and iron out issues and redundancies as we go, rather than holding out and waiting for clarity.
Go check out the specs and build bits of them and give the editors feedback!

ActivityStreams 2

We steamrollared through AS2 issues, which included core simplifications, vocabulary changes and reductions and editorial clarifications. James made most edits during the meeting, so there's a much updated working draft available now. You should read it and post any issues you see to be CR-blocking by the 15th of December.

JSON-LD related stuff has been moved to its own section; since it is optional, having references sprinkled throughout was confusing for people who don't necessarily want to deal with it. Chris pointed out that even for extensions, if you know the extension you want to handle you can still do that in plain JSON.

Still some consternation about which alternative syntax examples should be in the spec. Since they're non-normative/editorial anyway they're not a CR-blocker so left alone for the time being.

We don't need a verison number in the URL because any future widely-deployed extensions that want to make it into the core will likely be incorporated as part of a full new version (ie. AS3). At some point we should start a registry for extensions; James is keeping track himself on github, we could move this to a wiki page and ultimately a CG when the WG wraps up.

Lots of discussion about testing frameworks and how to meaningfully test production and consumption of syntax and vocabulary. I refer you to the minutes, as this is beyond my ability to summarise well enough, but it seemed like the people working on this gained some clarity and a plan to move forwards.

Social API

Editor's Draft all the things

There's some contention around what it means to accept a spec as an Editor's Draft in the WG. Our general consensus was that it means a spec isn't necessarily going to be rec-track, or even the direction the group is going to take, but it's in-scope and worth some portion of our attention, even if that is just to inform other things. Most specs we've picked up are work that the editors were doing anyway, and this just means the WG should explicitly not ignore them. It's expected that the specs will change significantly going forward, in response to input from the WG.

As such, it's okay that some of our now-ED specs currently cover overlapping territory. We hope that WG attention will serve to refine, cut, expand, merge, and otherwise sort this out. We may end up multiple small specs derived from our current set of EDs which cover pieces of the social puzzle, or several specs will demonstrate multiple viable ways of doing the same thing. My preference is for the former, but the latter is better than nothing. (I tentatively extrapolate the latter into either one gets wide adoption and the others quietly fade out, or they all get equal adoption and people build bridges between them, either way not a total loss).

Social Web Protocols

I finally convinced people to stop calling this "Amy's SocialAPI Document" and renamed everything to Social Web Protocols. This document describes the individual componants we are trying to standardise (based on user stories), covering both the API and Federation. Given the potential for the WG to produce multiple small specs, work on this is to continue to describe and serve as a guide to each building block. This should highlight both points of convergence between separate specs, and gaps that no existing specs are filling adequately.

Issues filed should be to that end. Point out obvious points of commonality between specs that I haven't noted, or where it would be worth replacing the vague overview with more spec-like details.

I aim to take this to FPWD next week (which does not imply WG consensus on the contents yet) with the expectation that this is currently an overview document: a guide to the different areas being standardised by the WG. If we end up with a bunch of small (or overlapping) specs, this could end up as a Note, detailing how they relate to each other as a guide to implementors. If we end up with one spec that covers everything, either this becomes it following input from the other drafts, or this has done its job at converging things and is dropped completely. The rationale behind going to FPWD with this document is to better advertise and explain the different angles of work the WG is doing to other WGs and the public, and to seek wider feedback thereon. The issues become a place to discuss features based on functionality, where they are not specific to one of the other individual specs.

ActivityPump and Micropub

Both now EDs. Micropub covers a subsection of functionality of ActivityPump, but is uncoupled from any other pieces of functionality, whereas ActivityPump intertwines lots of things. There are distinct similarities - both POST JSON to a specific endpoint to create, update and delete content. The editors are keen to cooperate so there's value in working on them both in sync.

jf2

jf2 is a social syntax to complement (not compete with!) AS2, where jf2 is content-centric and AS2 is activity-centric. The editors of both agreed that it would be beneficial to work on these in conjunction. I've written more about the relationship between them here.

Post type discovery

PTD is an algorithm to help consumers who find themselves with implicitly typed objects to derive explicit AS2 types, if that's what they prefer to work with. My concern is that it's biased towards the microformats2 vocabulary and currently useful for a niche - but a very small niche. However, James pointed out that types are actually optional in AS2 in general, so it could be expanded to help go from untyped AS2 objects to typed ones as well.

My other concern is that this space is such a moving target, and having a fixed algorithm to derive post types based on properties is going to get dated really fast. A constantly shifting algorithm doesn't fit into W3C workflow, and of course brings its own problems (who has implemented which version as it changes over time). I don't have an answer to this.

Federation: Realisations and moving forward

Evan forced us to slow down and really think about what we meant by federation. I don't know if anyone else did, but I had a bit of a lightbulb during this discussion. Bogged down in the particular bits of federation that are within reach to me (basically, notifications), I forgot there are a great many other things one might want to federate, like search, following topics, user discovery, recommendations... The WG is not required to tackle all of these, as a 'federation protocol' is the icing on our charter cake, but we absolutely don't want to de-prioritise federation completely as it's important and actually ties in well with a lot of the work we're already doing. But taking a step back to reassess - and clarify to the outside world - what we're actually doing is important, and there's some effort going into that now.

Webmention

Webmention has been an ED for a short while, and there were some issues to work through. Some really interesting points have been raised around technical details, security concerns and functionality enhancements, and lots of different ways to refine this spec are emerging. We talked through open issues, and group resolutions were made for most of them.

The one I'm most interested in is addition of the property parameter for better disambiguation of the assertion being made by a webmention. It surfaces a need of people outside of the current core webmention implementors to send and verify claims more precisely, whilst adding minimal additional overhead for those who don't need it. Since bringing this spec to the WG is an effort to gain wider adoption and investigate broader use cases than what we have at present, taking these kinds of expansions seriously is good. The benefits were positively acknowledge overall, and I was hoping we'd see this added to the current version, even if marked 'at risk' pending future implementations. But the decision was taken to leave it out, in the same vein as AS2 currently relegating all addition suggestions to extensions. On the plus side, the webmention spec will link to all proposed extensions which are written up as specs, and if any extensions see enough adoption over the course of the work they can be integrated into the core.

Cooperation

Bridging between worlds has been an ongoing theme in this WG.

Chris has done some great work on Activipy, a Python library for handling AS2, and overnight between meeting days he added support for jf2 as well by simply passing in an alternative JSON-LD context. This means you can pass in AS2 and serialize out again as jf2, and vice versa! More or less, at least... this might even be improved by adding PTD in between for where mappings aren't already obvious.

In general, tensions between specs that could be overlapping have changed to editors supporting each other to drive all of the work forward, and, I'm hoping, to optimise where redundancies exist. We all have the same goals, after all. We've still got a long way to go, but we ended on the feeling that we can probably get there.

And we played almost no SocialWG bingo, so it must have been a good meeting.

🏷 activitypump activitystreams as2 federation indieweb jf2 meeting mf2 microformats micropub phd social protocols social web socialapi socialwg standards w3c webmention

Mon 7th of December 2015 at 11:59pm (+00:00)

Render reposts of tweets properly

🏷 http://vocab.amy.so/blog#Todo http://vocab.amy.so/blog#Todo hacking mf2 microformats2 microformats parser slogd twitter

Thu 21st of May 2015 at 12:44pm (+01:00)

Post and Activity types

Recently I've been trying to wrap my head around the implicit vs. explicit post types debate (in the Social Web WG, indieweb community, and elsewhere). Here is some analysis of the different perspectives, and report on my own experiences so far.

tl;dr

I think each side of the debate about explicit vs implicit types are misaligned, due to conflation of Objects and Activities. I think Objects (like blogposts) needn't have explicit types, but Activities (like the act of creating a post) should do.

Thanks to Tantek, Aaron, elf Pavlik, Chris and everyone whose conversations I've listened in on in #social and #indiewebcamp IRC channels for discussing this stuff with/around me.

Indieweb: focus on UI

Indieweb development starts with thinking about UI. The reason for thinking about different kinds of posts comes from a desire to display some posts differently to others. But rather than declaring them outright, one can infer how to display them based on the properties of a post (see also IndieWeb Posts by aaronpk.

"explicit post/object types are architecture-centric design, rather than user-centric design" - tantek, #indiewebcamp irc

Posting UI

Another rationale against explicit post types is that it encourages posting clients to constrain users regarding what kind of posts they can create.

"...content types dictate the kinds of content you actually allow people to create with your software" - benwerd, The tyranny of content types

Most mainstream social networks now have a generic posting interface, that allows one to add things like photos, videos, people tags, etc, without forcing you to choose what type of post you want to make first.

Software architecture

Some people started with explicit post types and ran into problems when structuring their software around this idea. TODO: Citation from aaronpk in irc in March/April that I can't find right now.

URL design

If you include a slug for a post type in your URLs and decide to change the post type, this is definitely a pain. I figured this pretty early and dropped it from Slog'd. See also: Update URL Scheme issue for p3k.

On the other hand:

"but including type [in URL] because I like clustering by type in a day" - tantek, #indiewebcamp irc

... which I think relates to querying, discussed later.

Clarification: content-based vs intent-based post types

Often photo-type-post vs article-type-post is thrown up: ie. if you start with an article, then edit it to add a photo, does the post type change? I completely agree that typing based on content doesn't make sense here. When I talk about post types, I'm referring to types for like, bookmark, repost, log/metrics (eg. food, sleep), where they may look like a note in terms of content, but aren't. I display different icons for all of these at the moment, and you'll note that twitter for example displays retweets differently in the timeline.

Post all the things

Conclusion: in the indieweb community, so far, everything created is considered a post (a h-entry in microformats), and display differences can be inferred from properties of the post.

an article is a post with a title.
a like is a post with a like-of.
a reply is a post with in-reply-to.
etc.

ActivityStreams2.0

ActivityStreams2.0 has explicit object types and explicit activity types. It's easy to conflate them; I think this is what is happening when discussing types in AS2 with indieweb people, and I certainly had this problem for a while.

Taking an action generates an Activity, which might result in an Object (like a post).

Beyond posts

Contrary to indieweb stuff so far, AS2 allows for the idea that not every action on the social web results in a post. Having been immersed in indieweblogworld for ages, this was briefly a hard sell, but then I started to think of social actions (activites) I might want to take - that it's reasonable to want to publish in a feed - that I probably don't need to create a post for. Eg:

edit a post (or a wiki page)
git commits
follow someone
reading/viewing/watching something
blocking someone / reporting content
joining or leaving a group

I don't publish any of these activities on my site yet. There are some activities I do publish with posts (or plan to imminently), that don't necessarily (I might need convincing on some fronts) need to be posts:

likes
reposts
bookmarks
eating, drinking, sleeping (See Llog).
exercise, specifically running and yoga
listening to music
acquiring physical objects
arriving at a destination (aka checkin)

Activities vs objects

An Activity can be generated for any action.

Publishing a blogpost could generate in a Create activity, for which the object is the post created.
Bookmarking a page could generate a Save activity, for which the object is the page and the result is a post about my having bookmarked the page.
Editing a post could generate a Update activity for which the object is the post being edited, but there is no new post as a result.
Liking a post could generate a Like activity for which the object is the post being liked, but there is no new post as a result (if you're into that sort of thing, so far I'm not).

I strongly feel that all Activity should have URIs so that if it doesn't result in a post, it can still be interacted with (eg. you can like my edit). (However, this presents another point for confusion: when do I like a post, and when do I like the fact you published it (the create activity). Anyway, this is for another time..).

Since activities are generated as a result of an action, not explicitly created by a user (unlike objects), arguments for not explicitly typing them fall down:

you're unlikely to need to edit an activity, causing a need to change its type.
post creation UIs have nothing to do with this. Instead, UIs for interacting with posts such as webactions - but typing in these seems to be acceptable.

If you want to generate an activity stream from your actions, we do get an additional argument for explicit types of objects: it makes it much easier to generate a suitable Activity.

Querying

Explicit types for objects or activities make it easy to query by type. Inferring types - particularly from a combination of properties - complicates this a lot. I recently temporarily dropped quicklinks to /articles and /notes in Slogd after removing sioc:BlogPost and sioc:MicroblogPost as explicit post types made it suddenly more complicated to get them. Given a stream of many people's activities from all over the place how do you filter for specific things?

Human-friendly display

Displaying an activity (the fact that someone did something) is different to displaying an object. You might want to form a sentence ("alice likes bob's tweet") without caring what the properties of the object or possible result are. It's easier to figure out how to display it if it just has a type, without needing to follow links to the object or possible result to infer what's going on.

Generating activity streams

I guess... If you want to take a bunch of objects and generate an activity stream from them, and they don't have explicit types, it's totally up to you (an implementation detail, aka plumbing) how you decide what types the corresponding Activitys have.

I'm not sure if it would be nice to have something in the AS2.0 spec to help with consistently deciding how to infer activity types from object properties. Maybe it doesn't matter.

...Wait, is this ISSUE-4? Lack of explicit mention of activities or objects makes it hard to tell.

Conclusions

Every creation of a post should (can) generate an Activity.
Not every Activity-generating action needs to result in a post, but it's cool if it does.
Activitys need types. Objects (like posts) do not (necessarily).
If you don't want to generate a stream of all of your possible actions, but rather a feed of objects (as appears to be the case for indiewebbers so far) then you don't need activities, and this conversation is basically irrelevant... but if you think someone else might generate an activity stream from your objects, you're at their mercy regarding Activity types.

Next?

I should probably generate an AS2.0 feed from my posts.
Start integrating non-post-resulting activities into it.

Other notes

I went through the lists of Activity types and Object types in current draft of AS2.0 vocab and did a first pass at things I am using, might use and probably won't use. I'll publish this in another post.

I drew lots of diagrams of how I'd turn my different types of posts into Activitys based on their properties (how I'd infer activity types from object properties). I'll also type these up for another post.

Activity is a subclass of Object in AS2. Practical and conceptual differences could be discussed in more depth, but include things like ephemerality of activities vs objects.

Further discussion (possibly): https://lists.w3.org/Archives/Public/public-socialweb/2015Apr/0048.html

🏷 http://vocab.amy.so/blog#Doing http://vocab.amy.so/blog#Doing activities activitystreams2.0 activitystreams feed hacking indieweb mf2 microformats2 post types social web

Sun 12th of April 2015 at 7:47pm (+01:00)

Last modified: Sun 12th of April 2015 at 10:19pm (+01:00)

Microformats2 RDF Ontology

I'm serializing the microformats2 vocabulary into RDF; repo on github.

Disclaimer: This post is (not necessarily coherant) notes as I go along.

Useful notes by Tom Morris about mf2 to RDF mapping on the microformats wiki. I updated the namespace to use the one suggested there (http://microformats.org/profile/).

Everything starting with h- looks like it's a class. Typically RDF classes are capitalised so this makes me cringe, but I'll cope.

Woah, there are a lot of properties. Seventy unique properties. I didn't realise. On the wiki most don't have a description, many are duplicated in the list, and none of them seem to have their own description page (and thus no URIs to refer to them with). Pasting them into a spreadsheet was the quickest way to de-dup and alphabetise them. Now I'm working through one at a time, adding descriptions and mapping them to existing properties in FOAF (because many are obvious), VCard (because many (all?) are derived from this), ActivityStreams 2.0 (because SocialWebWG) and hesitantly Dublin Core and SIOC. Where they map to something well-described in RDF, I don't bother with rdfs:comment and domain and range of their own, but I'll add for those with no good sameAs mappings.

Is dt-reviewed same as dt-published? If not, why do reviews get special treatment with regards to differentiation between when they're written and published, and nothing else does?
Is there an official definition of e-content? Couldn't find one on the wiki, so made one up that is compatible with AS2.0 content, with additional caveat about including markup, which is explicit on the mf2 wiki: "The contents of something like a post, including markup and embedded elements."
Are e-description and e-instructions sub-properties of e-content?

I keep getting caught out by AS2.0 terms that are in the JSON-LD document but are actually deprecated (the JSON-LD contains no information other than property and class names and sometimes types; I have to remember to check the written docs). Eg. as2:author -> as2:attributedTo.

I couldn't find an AS2.0 equivalent property for category. Am I missing something? Oh wait, tag will do it.
How does p-description from p-summary?
Wiki says p-education should contain a nested h-card (of school and location). Doesn't that mean it should be an e- or have I misunderstood that completely?
It also says p-education is "an education h-calendar event" but h-calendar doesn't exist, it's h-event. Probably just a typo? Ditto p-experience.
ActivityStreams2.0 doesn't have a name property for Actors (only displayName). Interesting.
Wiki says label 'new in vCard4' but vCard4 says it's deprecated, and in any case was for address labels, so not sure what use this is in mf2.
What's p-note for specifically?
Why is p-reviewer not just p-author?
Maybe I just don't know how to read the vCard4 spec, but the mf2 wiki says sex and gender-identity are part of it, but all I can see is hasGender.

AS2.0 has rating but it's explicitly defined as "a non-negative decimal number between 0.0 and 5.0 (inclusive) with one decimal place of precision". MF2 says it's a number between 1 and 5. I think even less specification is better, as ratings come in come in many forms. Anyway, because I'm not venturing into SKOS, I'm owl:sameAsing them for the time being.

Update: Dropped all domains and ranges because all properties in microformats2 are actually global.

🏷 http://vocab.amy.so/blog#Doing http://vocab.amy.so/blog#Doing activitystreams as2 foaf hacking indieweb json-ld linked data mf2 microformats2 ontologies ontology owl rdf socialwg vcard w3c

Sun 22nd of March 2015 at 3:00pm (+00:00)

Last modified: Tue 28th of April 2015 at 5:49pm (+01:00)

Permalinks and webmention

As mentioned in Blog Post URIs, I'm a bit concerned about people replying to the 'wrong' URI for a post. That is, using the URL of a HTML page with the post rendered within it, rather than the post's permalink.

I couldn't find a Microformats2 term for permalink, which I thought would be the obvious solution.

The webmention 'protocol' says that when I recieve a webmention:

Check the target is a valid URI on my site after following redirects.

In my case, upon recieving a target of a https://rhiaro.co.uk/yyyy/mm/id, to validate it, rather than 'following a redirect' I'll actually be getting it's foaf:topic from the triplestore, which is fine. But in accepting this as the target I'm confirming to the sender that this is the correct URI to reply to. Hypothetically this non-permalink could break, breaking the reply. The permalink URI is one I'm promising won't break, so it's in everybody's interests to send the reply there. But logically, if somebody is linking to me in a post of their own, they're going to want to link to the rendered version, rather than whatever my raw version will look like (probably crappy, but that's on me, and maybe part of the problem).

Replying to shortlinks

Because I'm a linked data nut, my problem derives from a deliberate differentiation between a blog post and a page about a blog post. The connection between them (or from one to the other) can be discovered through RDF, but there is no HTTP redirection. I suspect this is a very much minority use-case for #indieweb folks.

However, use of shortlinks is widespread (and you can see redirects are accounted for in the webmention protocol), and so as soon as someone's URL shortner breaks (or moves) permanently, unless they store the post contents and metadata themselves, they might have to have to think about this a bit.

Solution?

I'd like to be able to send back the correct URI (303 redirect style) so the sender can either:

try again with the correct URI,

update their system with the correct URI, knowing I've accepted the webmention against the correct URI on my end (more like a (2NN)[http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00] than a 303).

I haven't looked at any implementations yet or thought about how to do it, so maybe I can just do this. I'm not sure how to anticpate people handling it.

Straw poll: What do you/your system do if you send a webmention and it's rejected, though you're sure the target is valid?

And if you're going to send your reply as a webmention from your own system, please target this post's permalink - the URI without a year and a month in :)

🏷 http://vocab.amy.so/blog#Doing http://vocab.amy.so/blog#Doing hacking indieweb learning linked data mf2 microformats2 microformats permalinks slogd uri webmention

Sun 4th of January 2015 at 7:17pm (+00:00)

Last modified: Sun 4th of January 2015 at 7:17pm (+00:00)