Train from Edinburgh to London
50.40gbp (expensed) (£50.4)
Post created with https://apps.rhiaro.co.uk/latinum
meeting (15 out of 31)
- Went to London. Got total culture shock. Too many people in too small spaces. No stars. so loud.
- Started The Lefthanded Booksellers of London (though I haven't finished The Overstory but the former was lighter for taking on a trip. Also thematically appropriate.)
- Recorded a podcast?! (as a guest).
- Had IRL TAG meetings!
- Did IRL Co-op coworking!
- Saw IRL friends I haven't seen for years!
- Returned from London. Two-day long migraine immediately went.
- Ran to Seafields.
- Attended the DID Working Group not-face-to-face meetings (a good time!).
- Fell ever further behind on nanowrimo, but kept plugging away.
- Invested in a bike helmet and lock...
- ...went cycling! With some random friendly locals, during a torrential downpour (not really random, it was a Greener Kirkcaldy community bike ride, but I was the only one who showed up).
- Attended a Social Web Incubator CG meeting and got some stuff done for a vocab collaboration with the DID WG.
- 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!
- Proponants of each protocol started to really understand how the other protocols worked, in a way that just reading all the specs couldn't do.
- Everyone really started to see where some protocols were strong and where their own weak points or gaps were.
- Everybody started to express that their protocols aren't complete and entertain the idea that they could make changes.
- We started to get a feeling of how the three protocols could complement each other well, and the feeling of competition between them was gone.
- We started to get really excited about making this happen.
- Sandro said he could see how Micropub and SoLiD were similar/complementary (SoLiD advocates seem keen on adding webmention for notifications).
- Aaron and Jessica agreed that ActivityPump and Micropub were actually way more inline than they realised before.
- I can see the ways in which ActivityPump and SoLiD are similar, and Evan also noted the complementary nature of the two.
Edinburgh to Dysart 🚌
Leaving Edinburgh, Scotland at 8:30pm (+01:00) on Friday the 24th of June 2022 and arriving in Kirkcaldy, Fife, Scotland at 9:43pm (+01:00) on Friday the 24th of June 2022
Return from Co-op coworking.
Dysart to Edinburgh 🚌
Leaving Kirkcaldy, Fife, Scotland at 7:50am (+01:00) on Friday the 24th of June 2022 and arriving in Edinburgh, Scotland at 9:13am (+01:00) on Friday the 24th of June 2022
Co-op governance coworking.
Week in review: 21st - 27th March
Post created with https://apps.rhiaro.co.uk/no-ceremonies-are-necessary
The early starts and late finishes and squeezing the day job into the gap in the middle were a lot, but I really enjoyed this week's virtual TAG face-to-face. Productive, and fun! Can't wait til we can do it in three dimensions though.
Post created with https://apps.rhiaro.co.uk/no-ceremonies-are-necessary
Week in review: 2nd - 8th Nov
Post created with https://apps.rhiaro.co.uk/no-ceremonies-are-necessary
8th Social WG F2F
☑ Attending!
RSVP
Amy RSVP'd to https://www.w3.org/wiki/Socialwg/2016-11-17Our final spec party.
6th Social WG F2F 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.
We met in Portland on 6th and 7th June. What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome. This doesn't cover everything we talked about in detail; as well as the following, we resolved (or at least discussed) issues on all of the specs, and took a few to new Working Draft status.
Demos
I demoed my ActivityPub implementations; clients Burrow for checkins, Obtainium for consumption/purchase logging, Replicator for food logging and Seeulator for journeys and events. These all do create only by sending either appropriate activities (including some extensions) to my activitypub endpoint (aka outbox, but not discoverable as such yet).
Seeulator creates the right kind of activity based on what attributes are filled in or left blank, essentially doing post-type discovery - albeit my own algorithm rather than tantek's spec from the user input to generate the right as:Activity.
The newer thing I worked on was a client that only does updates of existing AS2 data. I wanted this so I could add captions to all my photos at img.amy.gy, so Morph does just that. This also means it has to be able to read/consume the AS2 data published at img.amy.gy about as:Collections of photos.
Aaron demoed the Webmention test suite at webmention.rocks and notes that there are Webmention Rocks stickers available for people submitting implementation reports..
Aaron also demoed a new feature in the Micropub spec which is the media endpoint. After some discussion recently it was established that all mainstream social APIs seem to post media (like images) that have been embedded in a post to a separate endpoint, then embed the returned URL in the post content, and MediaGoblin does this too. Aaron's implementation in Quill is really swish looking, uploading the file to the discovered media endpoint whilst you're typing the rest of the blog post, then embedding it back in the UI so you can see it straight away. I should probably implement something along these lines, and sync it up with what ActivityPub is doing (which is going to be basically the same); it's especially useful as I host my images on a completely different domain and stack from my blog posts and right now I have a by-hand process of uploading images to one server, then copying the URL into a blog post to embed.
Evan showed the Wordpress plugin implementation of AS2 by pfefferle, demonstrated on his fuzzy.ai blog. We all noticed a few bugs and AS1-isms in the implementation, but all correctable and all good flags for when we give advice for people switching existing implementations from AS1 to AS2.
Modularising ActivityPub
For a while I've been pushing to break ActivityPub up into several separate specs for each part, modularised by functionality, reasoning that this will lower the barrier to both CR and conforming implementations. I feel strongly that distinct functionalities should not be dependent upon one another to conform to the spec; ie. if I only want to implement subscribing/reading in my application, I shouldn't be required to implement creating new content as well. I've been back and forth on this with Chris and Jessica for at least a year and we're all getting closer to understanding one another. The WG resolved at this meeting to split into ActivityPub (reading, creating, updating, deleting content) and ActivitySub (name pending; subscription and delivery of content). It took me a little longer than it should have to really grok how closely tied 'delivery' and 'notifications' are, but now I realise that regardless of what triggers 'delivery' of an activity, the process of 'delivery' to someone's inbox is the same. The triggering part can be a subscription (a special side effect of receiving a Follow activity) or a notification (an activity or object is created which is addressed to or links to a user or other activity/object). Thus I anticipate ActivitySub describing how the triggers work, then how delivery works upon a trigger. I'd still like to be able to conform to the 'delivery' part without worrying about the 'trigger' part (maybe I want to implement an entirely different subscription trigger mechanism) but this can be achieved with conformance classes if splitting the spec up further is too much.
New work
The working group wraps up at the end of 2016. There's still time for us to work on new specs, but the ideal is that anything new being presented to the group will have been incubated (worked on, tested, implemented) outside of the group beforehand, either in a CG or other community or organisation. Coming soon to an editor's draft near you: PubSubHubbub!
Next meeting
We confirmed we'll meet on Thursday and Friday at TPAC in Lisbon in September. We'll also run a social web breakout session on the plenary day (Wednesday) like we did last year.
5th Social WG F2F 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.
We met in Boston on 16 and 17 March. What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome.
ActivityStreams2
AS2 is inching closer to CR. Evan has made a validator at as2.rocks and done a lot of work on conformance criteria which we went through as a group and updated a little; mostly changing SHOULDs to MUSTs.
Discussed and not necessarily resolved a few new open issues, including: considering dropping the Relationship object and reviving it as an extension if necessary; a proposal for a new property to say when something was deleted; weakening the SHOULD requirement on name; clarifying scope and context.
Stay tuned for a new working draft sometime soon.
SocialPub
The most exciting thing I thought was agreeing on the potential for convergence between the create, update and delete parts of Activitypub and Micropub.
Micropub started life as a super small and simple way for clients and servers to agree how to create content on a website by POSTing form encoded parameters to an endpoint. As a result of this simplicity, there are dozens of client and server implementations, allowing people to use each others posting clients to add posts to their site, from simple text-only posts to photos, events, RSVPs, likes, bookmarks, reposts. When Micropub needed update and delete, it grew beyond what form-encoded parameters could sensibly handle, and added in a JSON syntax which I think to date only the editor has implemented.
Activitypub uses a JSON syntax (ActivityStreams2) from the outset for create, update and delete, and when you compare this with the Micropub JSON they look remarkably similar.
My posting endpoint implements create the AP way, and endpoint discovery the MP way. It also catches Micropub form-encoded requests and translates them to AS2 JSON before proceeding, so I can still use simple Micropub clients. My posting clients burrow (checkins), obtainium (purchases), replicator (food) and seeulator (events, RSVPs, travel plans) all post AS2 JSON... after discovering the endpoint via rel=micropub. Next on my list, and well overdue at this point, is adding update and delete to both server and clients.
So I proposed we write a document that unifies the common parts of AP and MP, iron out the smaller differences, and hope this coalesces into a small create/update/delete spec which both AP and MP can reference rather than duplicate. Because modularity is good, and common modules are better! I dubbed this temporarily (or is it?) SocialPub.
So what's left in Micropub? I hear you cry. The super simple form-encoded create which is what made Micropub do so well in the first place is really what makes Micropub micro, so I'd like to see this be the bulk of the Micropub spec, with just a pointer to SocialPub for people who want to level up to JSON.
There are still more than a few issues to be dealt with, though we handled a few during the meeting (such as media uploads). I'll be writing SocialPub up into the Social Web Protocols doc next week, stay tuned.
Demos
Jessica and Chris demo'd Media Goblin federating with pump.io! Which is cool. Which brings them a huge step closer to implementing things with AS2/AP and federating that way. They discussed how one of their main impediments had been database schema migration.
Aaron demo'd his Micropub editing UI, which allows partial edits on the post, only for data he is most likely to want to edit (tags, syndication URLs and date).
Aaron also demonstrated a new event posting interface in Quill which uses Micropub, and showed how RSVPs from Woodwind (a feed reader) work via Webmention. Tantek and Ben also demo'd RSVPs from their sites. And Ben demo'd how he can post reactjis as replies, exemplified with the poop emoticon, and there is no question that the future of the social web is in safe hands.
Frank demonstrated federation between OwnCloud servers, which uses WebDAV and CalDAV, and talked through their access control.
Admin/Process
We also had a couple of admin/process related discussions. The first included agreeing to meet at TPAC in Lisbon in September as it already looks like there'll be critical mass to make it worthwhile.
Sandro has made a list of issue labels for github which we painstakeingly went through to make sure everyone understands them and editors are willing to use them on specs. This should help people to figure out at a glance what the current state of a spec is from the issues, as well as help passers-by to jump in if they want to get involved.
In reply to: http://crosscloud.org
In reply to: http://sociam.org/
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
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.
SOCIAM all-hands
☑ Attending!
RSVP
SOCIAM all-handsToday's SocialWG telecon location:
And the SIP connection is better here than in my office, which seems like a perfectly reasonable justification for staying here always.
Social Web WG 3rd face-to-face summary
This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!
tl;dr: There is increased understanding and expectation of convergence between Micropub, ActivityPump and SoLiD. We're all excited about working towards this convergence. There is increased agreement and understanding about similarities and differences between protocols, and where strong points of one protocol could plug weak points in another. More people are excited about implementing experiments to really figure out what works and what doesn't.
See also day 1 minutes and day 2 minutes and self-critique whiteboard.
What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome.
Issues in the tracker
Closed a bunch of ActivityStreams2.0 issues with the general conclusion that issues raised in future should be more specific and actionable, rather than vague problems. An alternative for reporting this kind of issue wasn't mentioned specifically, but vague problems can probably go in brainstorming sections on the wiki somewhere (indieweb style) or into github issues.
A note that we can always re-open issues if they turn out to be a problem in the future, but we shouldn't keep them open just in case they might be.
Awesome user-story protocol walkthroughs
Aaron, Jessica and Andrei and Henry walked us through exactly how some of the user stories would be carried out according to the protocols Micropub, ActivityPump and SoLiD respectively. This was super useful, and if you weren't there you need to read the accompanying documents (linked just prior) and minutes (linked at the top of this post).
Results of this were:
I particularly noted:
That's a full triangle of connections! The protocols are all friends.
The resolution, then, was that we won't rush to pick a base to work from, and instead will spend some more time (with regular updates to the group) tweaking each protocol to get closer to convergence, so everyone will be happier when a base does eventually need to get chosen.
(Exciting, right?! This was like the best meeting of minds that has happened so far. If you weren't in the room you might have missed this, so... trust those of us who were).
Extensibility
There should be some kind of clear warning in the spec that extensibility won't work well if you're using plain JSON, not JSON-LD (implying the best way to do vocabulary extensibility is through URI namespacing, which hasn't neccessarily been agreed, but to me seems like a sensible way). It also needs to be clear that upon receiving terms that a server does not understand it should not drop the data, even if it ignores it - in case that data gets passed forward to a server that might understand it.
We resolved "ISSUE-36, Remove all non AS2 namespaces from the normative context, keep the normative context limited to only AS2 vocabulary terms". I'm not totally sure what this means: that if there are terms we decide are crucial we will include AS versions of them even if they already existing another vocabulary (instead of reusing)? In the name of 'completeness' might we overload ActivityStreams, and because we consider AS 'complete' risk sabotaging easy extension? I still don't get everything that is throw around during extension mechanism conversations, so I could be missing something. Mostly I'd love to see someone implement AS and extend it to a specific domain, to see how this would work in practice. On a related note, I don't think I've seen documentation of the use-cases / origin of all of the vocabulary terms in AS2, does this exist?
Activities vs objects binary is false
The activity-oriented model of AS2 and the object-oriented model of microformats are actually basically the same but looked at from different perspectives. I think it's really important people try to see this, and not see them as conflicting. We're all trying to do the same thing, and there's no reason AS2-based and microformats2-based implementations can't interoperate. I'm going to work more on this, and others are too. We closed issues related to this as too vague, but it'll need revisiting when we have some more concrete proposals about what to do. By the end of the two days, people were starting to generally agree that this is the case.
People and profiles
We clarified that Person in AS2 does not need to refer to a real-world person, and agreed we should make this clearer in the spec (eg. it could be a fictional person, a persona or aspect of someone, etc). We resolved to add Profile to AS2 to enable talking about documents about people separately to talking about people, and to facilitate connecting one Person to multiple Profiles, which I think is useful but not everyone agrees. Thus Profile is at-risk until there are implementations.
It's worth emphasising the two different parts of this discussion: Person vs. Persona is different from Person vs. Profile (ie. Person != Persona != Profile). There was some conflation of this during discussion. Whilst everyone tends to agree that there are three different things there, we disagree about which level of modelling is practically necessary. Figuring this out based on observing how existing social sites model this, implementing my own aspect-based profiles, and shunting my own data around between different profiles, is something I'm concentrating on over the next couple of months.
Clients and servers
Describing things as client or server can be misleading. Things act as a client or server depending on the perspective, and it doesn't necessarily matter if they run in the client or on the server. We either need to clarify or alter our terminology, perhaps rephrasing to describe which componants we see having which responsibility.
Namespacing terms
Not at all, with strings, with URIs? Uh... decent arguements for and against all, strong opinions all around. I dunno.
Audience targeting vs group membership
Subtle distinction between access control via the author of a post deciding who to send it to (or who can see it), and someone actively joining a group in order to see additional content.
In ActivityPump (and pump.io) you specify to to decide who can see a note, eg. your followers. If someone new follows you, and someone else unfollows you, then you update your note, which list do the changes get propagated to? The original receivers of the note, or the current list of followers? I think this isn't specified and needs to be clarified. In ActivityPump, following someone is effectively adding yourself to a group (Collection) of their followers.
Side effects and propagating changes to the social graph
LDP doesn't have any side effects by itself, it's simply posting and getting of data to a generic store that doesn't understand the data itself. But for more domain specific purposes like social, LDP could be one layer with another layer that handles side effects like notifications and distribution of changes.
Certain activities in ActivityPump cause specific side effects. This is a fixed list, and could do with being better described in the spec. These are things like: if A creates a follow activity of B, side effects are A is added to B's list of follwers, B is added to A's list of followings, B is notified that A followed them, and anyone with permission to see A's activities also sees that A followed B. From what I can tell, side effects tend to be updating/deleting objects or adding to/removing from collections.
Micropub's side effects could include syndicating a post to other sites, or triggering webmentions (notifications). There is increasing discussion about having a following list that a reader can subscribe to (so you don't have to enter all of your subscriptions if you change reader) and keeping track of when you followed/unfollowed someone; actively doing one could trigger the other.
My vague conclusion is that specifying an extensible way to describe side effects of activities would be useful, with perhaps some core musts and shoulds, but open ended for implementations to do more focused things (eg. if Floop-o-matic decide that posting a Floop automatically likes the second most recent post of everyone named Fred, then they could describe that in a spec-conformant way. Okay that was silly, but you know what I mean).
RESTful vs endpoints
LDP is RESTful; Micropub (and Webmention) use discoverable endpoints; ActivityPump mostly uses endpoints (specific paths rather than discoverable I think) with some things able to be done RESTfully. Endpoints mean services can be delegated to third-parties, and can therefore be used on static sites. Not sure if there's a specific benefit to RESTful (or RESTfulish) but with a bit of sideways thinking they could actually co-exist, allowing implementers to use the method they prefer.
Cooperation++
General observation: We're all working towards the same thing. Nobody in the group is trying to sabotage this effort. I don't think it would hurt to listen more, and maybe imagine that you want someone else's [solution|use case|constraint|idea] to be better than yours, and try to fit it to your world, instead of just insisting one is the best.
Every community has different constraints, and different use cases they're trying to solve. We can't elevate one set of requirements above another, but need to try to accept - or at least entertain the idea - that they're valid, without dismissing them outright just because you haven't experienced it directly. Periodically mentioning the business use cases from IBM and Boeing (for example) is helpful in reminding everyone that there are legitimate long-standing needs that probably aren't considered by most of us, but will be implemented if we support them, and will be implemented some non-standard way if we don't.
Addendum
TimBL made sure to remind everyone that JSON is 'in fashion' just as XML once was, and really everyone will regret not just using RDF from the start in the future :)