pius is right (hey, pius!): FOAF+SIOC - you can reuse the RDF ontologies inside OPML as XML namespaces.
And some recent prior art that shows how to REALLY do it wrong: TweepML. I wrote up a page the other day explaining what's wrong with TweepML - http://gist.github.com/223649
Jesse Stay
· 1 month ago
Dave Facebook does support lists - they have for over a year now. It's all available via their API.
Chris Messina
· 1 month ago
Hi Dave,
I'm curious, as Tom Morris suggested, how this differs from the Portable Contacts effort that's already gained widespread support in OpenSocial? It defines a straight-forward approach to syndicating contact information in JSON using a combination of the vCard and OpenSocial schemas. Everything that you've proposed here (except "xSocial:userStatuses" and "xSocial:userFollowedBy") are covered by prior art.
I'm thinking you might see faster adoption in the marketplace by leveraging this existing work? Perhaps you could suggest areas of improvements for Portable Contacts that would enable you to do what you want to do?
Is to encourage people to provide examples of alternate ways of doing the same thing.
As far as prior art for subscription lists, which is what we're talking about here, pretty sure I'm on solid ground using OPML. The only question is what to call the attributes that come out of Twitter. For that, I used the same terminology used by Twitter. I feel very comfortable in the size of the installed base (which was Chris's point). It's huge and growing all the time.
I think a lot of these efforts fail to get on board when the things they predicted actually start happening in the market. I learned that lesson a long time ago, in the 80s and early 90s when stuff I was doing was reinvented by Apple. I just got on board with their way of doing it rather than try to convince them to do it my way. That's why I'm doing it Twitter's way. Who cares what these things are called. What I care about are users. And today the people creating these lists are in Twitter.
Anyway, that's my thinking...
Chris Messina
· 1 month ago
Fair enough. Twitter certainly has momentum, and that's hard to argue with. One challenge, then, is to extract the essence of what's happening on Twitter to enable these activities to happen between different silos. Of course it seems to always be the case that the silos come first, develop the user experience and cultural norms, and then there are clones, and then someone comes along and adds value by breaking down the silo walls... so it will probably be with Twitter too, but for now there's just too much value in participating in their arena to allow an independent channel (say StatusNet or FriendFeed) to compete on mere technology alone.
I'll think about what it would take to get the data constructs you've outlined here into Portable Contacts all the same.
Mason Lee
· 1 month ago
Just some technical clarification here on XML namespaces and prefixes, based on the w3c spec: http://www.w3.org/TR/REC-xml-names/ . Hope this is helpful.
In your linked OPML example, the namespace is "http://scripting.com/stories/2009/11/08/aSocialNamespace.html". "xSocial" is what the document is using as a namespace prefix. Prefix choice actually doesn't matter. Once the xml is parsed, all elements are bound to a namespace according to their prefix, and the prefix is then essentially forgotten for most logical purposes (round-trip xml editing being a common exception). Equivalent XML could use the prefix "foo" instead, as long the document declared xmlns:foo="http://scripting.com/stories/2009/11/08/aSocialNamespace.html".
In sum, XML developers should be careful not to make assumptions about the prefix string being any specific value, and you should probably be advertising the namespace value in this post instead of the prefix name. You can change the prefix a hundred times a day-- only the namespace need remain constant.
dave
· 1 month ago
Ohhhhhh but they do make assumptions. :-)
I think there's even validators that enforce them.
All Comments
pius is right (hey, pius!): FOAF+SIOC - you can reuse the RDF ontologies inside OPML as XML namespaces.
And some recent prior art that shows how to REALLY do it wrong: TweepML. I wrote up a page the other day explaining what's wrong with TweepML - http://gist.github.com/223649
I'm curious, as Tom Morris suggested, how this differs from the Portable Contacts effort that's already gained widespread support in OpenSocial? It defines a straight-forward approach to syndicating contact information in JSON using a combination of the vCard and OpenSocial schemas. Everything that you've proposed here (except "xSocial:userStatuses" and "xSocial:userFollowedBy") are covered by prior art.
I'm thinking you might see faster adoption in the marketplace by leveraging this existing work? Perhaps you could suggest areas of improvements for Portable Contacts that would enable you to do what you want to do?
One of the reasons I linked to an example above..
http://static.listbrowser.org/opml/davewiner/en...
Is to encourage people to provide examples of alternate ways of doing the same thing.
As far as prior art for subscription lists, which is what we're talking about here, pretty sure I'm on solid ground using OPML. The only question is what to call the attributes that come out of Twitter. For that, I used the same terminology used by Twitter. I feel very comfortable in the size of the installed base (which was Chris's point). It's huge and growing all the time.
I think a lot of these efforts fail to get on board when the things they predicted actually start happening in the market. I learned that lesson a long time ago, in the 80s and early 90s when stuff I was doing was reinvented by Apple. I just got on board with their way of doing it rather than try to convince them to do it my way. That's why I'm doing it Twitter's way. Who cares what these things are called. What I care about are users. And today the people creating these lists are in Twitter.
Anyway, that's my thinking...
I'll think about what it would take to get the data constructs you've outlined here into Portable Contacts all the same.
In your linked OPML example, the namespace is "http://scripting.com/stories/2009/11/08/aSocialNamespace.html". "xSocial" is what the document is using as a namespace prefix. Prefix choice actually doesn't matter. Once the xml is parsed, all elements are bound to a namespace according to their prefix, and the prefix is then essentially forgotten for most logical purposes (round-trip xml editing being a common exception). Equivalent XML could use the prefix "foo" instead, as long the document declared xmlns:foo="http://scripting.com/stories/2009/11/08/aSocialNamespace.html".
In sum, XML developers should be careful not to make assumptions about the prefix string being any specific value, and you should probably be advertising the namespace value in this post instead of the prefix name. You can change the prefix a hundred times a day-- only the namespace need remain constant.
I think there's even validators that enforce them.