On Mon, Feb 1, 2010 at 1:04 AM, Michael Barinek <[email protected]> wrote:
hub.lat 39.51
hub.lon -76.24
If this is supposed to express a constraint on published items (a query),
what does it mean? Does it require an exact match? (If so, then I think
you'll find that very few useful applications of location data can be
satisfied with just an exact match...) Typically, one wants some radius
around a point in these applications. Thus, for this to be useful, you'd
have to add in a hub.radius value. Or, many applications will want to be
able to do things like say "east of this point" or "south of this point..."
How would that be expressed? (Or, "east of here but no more than 50 miles"?)
Consider as well that many location based applications require bounding
boxes, not just point and radius or position relative to a point. So, for
simple rectangular bounding boxes, you'd need at least two points. But,
these days, the bounding boxes that describe things like cities, towns,
counties, etc. are often expressed as polygons which require an arbitrary
number of points... How would you encode those? (Note: CAP -- the emergency
notification standard, uses polygons to describe events like earthquake
disaster zones...) And, many sophisticated applications use approaches
like Hierarchical
Triangular Mesh <http://skyserver.org/HTM>,
HEALPix<http://healpix.jpl.nasa.gov/>
, COBE Quadrilateralized Spherical
Cubes<http://lambda.gsfc.nasa.gov/product/cobe/skymap_info_new.cfm>
, Military Grid Reference System
(MGRS)<http://en.wikipedia.org/wiki/Military_grid_reference_system>or
the simpler Maidenhead
Locator System <http://en.wikipedia.org/wiki/Maidenhead_Locator_System> used
by amateur radio operators. An early adoption of a syntax for expressing
locations and constraints on locations might make later adoption of more
expressive mechanisms more difficult than it could be.
In any case, I would argue that we shouldn't be adding type or application
specific parameters to PSHB in order to handle one-off requirements --
especially since it is likely that we'll find that we need to combine
constraints in the future. I might want to subscribe to:
"Items published within 5 miles of here by Tom Jones that mention Pizza or
Sushi."
How would I express the boolean combination of "Location AND Author AND
(food1 OR food2)"???
This could be very difficult if the means for expressing constraints is by
using parameters. it would be vastly easier to accomplish if we had,
instead, a textual syntax (like a query language) for expressing these
things.
I suggest that we should be fairly careful not to move ahead with point
solutions that will either make progress more difficult in the future or
will inevitably end up with us eventually having multiple solutions to the
same problem. Let's first get the basic, simple PSHB up running and well
understood before we go too far down the road of adding complexity such as
content-based matching.
bob wyman
On Mon, Feb 1, 2010 at 1:04 AM, Michael Barinek <[email protected]> wrote:
oh, the example in my first post may have suggested a custom url although
lat/lon are just additional post parameters.
better example...
hub.callback http://your.hostname.com
hub.mode subscribe
hub.secret
hub.lat 39.51
hub.lon -76.24
hub.verify sync
hub.verify_token
Bob Wyman wrote:
There are many attributes of an item published via PSHB that one might
want to select on in order to build a custom feed. Location is certainly one
of the more interesting ones. However, there are many others. For instance,
it would be interesting to subscribe to the work of specific authors, not
just feeds. Or, feeds from anyone at a particular domain (like a company),
or all items that contain the word "Foobar"... Certainly, URL conventions
could be constructed to cover many of the common cases, however, what we'll
end up with if we go too far down that road is a situation where many items
are being published in multiple feeds (wasting resource) and we'll still
want to have the capability to do things like subscribe to words or phrases
in published items.
Personally, I think we should restrain ourselves from defining too many
URL conventions and instead think about the more general problem of doing
content-based subscriptions on aggregates of feeds. I think it would be best
to leave core PSHB itself as a simple "topic-based" system with a simple
core subscription syntax (i.e. subscribe by feed URL only...) and a
mechanism to pass "firehose" feeds to more complex subscription systems.
Then, we should define companion specifications for systems that would allow
content-based filtering of feeds in more complex ways.
bob wyman
On Sun, Jan 31, 2010 at 5:56 PM, Michael Barinek <[email protected]<mailto:
[email protected]>> wrote:
I'm not sure if location based "topics/feeds" have been discussed in
the past, but here's something else that I've been playing around with.
I've been including 'hub.lat' and 'hub.lon' parameters in
subscription requests and then filtering inbound feeds by location
(when available).
for example...
hub.callback=http://your.hostname.com&hub.lat=39.51&hub.lon=76.24
I'd be interested in getting feedback - interesting, not
interesting, doesn't fit...type stuff?
Here's a small application spike (still rough around the edges) that
I've been playing around withhttp://www.localhash.com/
Thanks
