Dear Danny, Thanks for this as I think this clarifies the problem -- in ways that I didn't. I agree that the solution (or solutions) has to be at the end point, or at least set by the end point. Also that it most certainly is not about the "perfect" feed. One person's perfect feed is another person's corrupt feed. However, the point I was trying to make, probably badly, is that in the world I come from, that of large scientific archives and datasets, end users don't have the time or the resources to do too much slicing and dicing. As they are usually also subscribing to very fat feeds, they don't want to be constantly getting masses of data PuSHed to them that they just have to throw away. On top of all this, the data we are looking at PuSHing can be used in any number of ways, by any number of users, so embedded tags are of minimal use. What "tagging" there is is already embedded anyway and will get used where and when it is helpful, but far from universally.
I suppose my problem is that with our feeds the vast majority of our users live, and always will live, in the very long tail. This means that embedded tags help to a degree, but only to define the most general interest set for the users. Maybe that is good enough and is up the them to sort out how to get to the more specific interest set, but I continue to think that it is not great problem to have some simple user set filtering as part of the hub management. So rather than (1) publish to hub, (2) hub strips old data from new, (3) hub PuSHes new feed data to subscribers, we get (1) publish to hub, (2) hub strips old data from new, (3) hub filters new data for each subscriber, (4) hub PuSHes filtered feed data to subscribers. Not complicated, but a missing bit perhaps? Best, Robin On 24 August 2010 12:14, Danny Briere <[email protected]> wrote: > So I'll chime in here because this is near and dear to my heart. I > too think that PubSubHubbub is a great technology but there are a lot > of business issues to take this to the next level. The question is > what is in the hub and what is in the end server/subscriber domain. > For my application, which is in the Marketing space, I am solving this > on the endpoints because this is largely the way that today's business > feeds are set up. Typically you subscribe to approximately what you > want to get from a feed and you expect to have to slice and dice the > data in some fashion. Unless you are paying for a fully customized > feed, you generally have to merge, purge and otherwise groom content. > So I'm not so concerned with trying to give someone a perfect feed; > rather, provide them with the information they need to make good > decisions over what they want to get. > > For this, we're pushing for embedded marketing-related tags, so you > could know that a bit of content is a white paper or an event or a new > release or whatever. So we see this as a necessary other half of the > equation -- without embedded tags, the information is near worthless. > It's like the impact that Google Search has had before and after its > vertical categorization into News, Video, etc. > > The problem we have had is that for embedded tags to really have an > effect you need some players behind you to step up and say they'll > "read" the tags. I've been trying to find people in Google, Bing, > Yahoo etc. who want to work to define these tags (I have such proposed > definitions created), but am struggling to get to the right people -- > I'll continue to hunt. > > In the end, I would offer that to try to do this in the hub starts to > sound a lot like the XML routing space that already exists and any > subscribing server can handle on their own. I'm not sure it needs to > be specifically in this hub spec. But I'm less a technologist than > most on this list. > > Danny > > On Aug 24, 4:59 am, Robin Boast <[email protected]> wrote: > > Dear all, > > > > I think that Niranjan's points are important, especially point 1. Coming > > from very large data repositories, I have found that PSHB still seems to > > think on the small scale, e.g. relatively small directed feeds. However, > the > > world I work in, which is perfect for PSHB, is large and dynamic > datasets. > > What my very diverse users want are feeds that they can filter. Now I am > > sceptical that metadata is the way forward here, but some form of > > subscriber-set filters would be essential when the feeds get very big. > > > > Best, > > > > Robin > > > > On 23 August 2010 18:00, Niranjan <[email protected]> wrote: > > > > > > > > > Hi, > > > > > Had a few thoughts on potential add-ons. (with business usecases in > > > mind). > > > > > These definitely fall outside the basic spec and may not be as > > > technically sound, and that's why i would appreciate some critique. > > > > > 1. Can Hubs be engineered to understand the message-content they > > > handle? If hubs are made content-aware (atleast through meta- > > > information/tags if not the entire content, keeping in mind security > > > constraints), they could double up as yellow-pages. This would enable > > > them to project themselves on their "reach" to other hubs in a > > > distributed topology, or to publishers so that publishers put their > > > best foot forward, offerings-wise, before linking with a given hub. > > > Subscribers could further state their interest in topic-categories on > > > Hubs and this would give further useful information to potential > > > publishers to adapt their business offerings accordingly. > > > > > 2. Is there any activity in the pipeline to evolve a standard set of > > > objects per business, now that there are (widely used)Hubs? Are Hubs a > > > nice place to enforce standards in business objects that pass through > > > them? (having a series of "superset" business objects, with > > > standardized field definitions per business, would reduce so much > > > effort in basic data-mapping, later in the ESBs.) > > > > > 3. Is there a directory to discover Hubs? Alternately, instead of > > > having exclusive directories, why not place a mini-directory inside > > > each hub/select hubs pointing to local hubs? This is analogous to > > > asking around for directions on the way to a place and leaving a trail > > > of knowledge on the way, rather than reaching a centralized board > > > displaying directions. If there were knowledge-based Hubs, the > > > knowledge-bank of each hub would keep increasing this way. > > > > > The gist is -- can one add a business dimension to this? > > > > > Regards, > > > Niranjan > > > > -- > > =================== > > Dr. Robin Boast > > Curator for World Archaeology > > Affiliated Research Scholar, History and Philosophy of Science > > +44 (0)1223 333515 > > [email protected] > > blog:http://rescite.blogspot.com/ > > GWave: [email protected] > > GTalk: robinboast > > Buzz: Robin Boast > > > > MAA Museum of Archaeology & Anthropology > > University of Cambridge > > Downing Street, > > Cambridge, UK CB2 3DZhttp://maa.cam.ac.uk/ > -- =================== Dr. Robin Boast Curator for World Archaeology Affiliated Research Scholar, History and Philosophy of Science +44 (0)1223 333515 [email protected] blog: http://rescite.blogspot.com/ GWave: [email protected] GTalk: robinboast Buzz: Robin Boast MAA Museum of Archaeology & Anthropology University of Cambridge Downing Street, Cambridge, UK CB2 3DZ http://maa.cam.ac.uk/
