I am performing simple event searches and am happily receiving results.
However, I've noticed the following pattern is quite common for a given
event:
- there is no displayable address. that is, the following both hold:
- venue_display is 0
- venue_address is empty
- the venue_name exists, but is incorrect.
- the (lng, lat) are incorrect
- the description field includes an URL to a mapping website.
- The (lng, lat) in the URL embedded in the description disagrees with the
event data. The URL is correct and the event is incorrect!
So far, I've only seen URLs to maps.msn.com, but others are possible. Please
reference the following eventId as an example. I have many others if you
want them:
eventId: E0-001-018640221-7
In order to present a unified view of the world, I plan to strip all links
from the description and present the remaining text. If I recognize the URL
as a map URL, I will glean the (lng, lat) from the stripped URL and override
the event's (lng, lat).
This is a 'lossy' solution--the event's creator expects the end user to have
access to the data he has provided and I won't deliver it. It is also a
dangerous solution, as I have little reason to believe the event creator has
the (lng, lat) correct in the embedded URL. After all, it's untyped data.
Further, it is a hack solution. I don't currently process the description
field until I present it to the user. However, I do process all (lng, lat)
for events upon receipt so I can display them simultaneously on a map.
Alternatively, I may just ignore all data that doesn't have an actual
address, given the event's (lng, lat) won't point to the actual location,
anyway. From what I've seen, this may cut 60%-80% of eventful's data from my
search results making eventful much less valuable to me.
Also in the example event above, the event creator provides the venue name
"Benaroya Hall" as untyped information in the description, but pollutes the
event's venue_name field with "Seattle, Washington, United States". Again,
the information in the description field is accurate while the information
in the event itself is inaccurate. As before, the accurate information is
not useful because it is untyped.
At present, I don't have a better solution. So, I'm calling in the Big
Guns--the eventful team to see if we can attack the root cause of the
problem.
The problem stems from the fact that the event creator is allowed to supply
arbitrary data in the description field. These event creators are abusing
the description field as a kitchen sink, supplying data which isn't
necessarily consistent with the typed data already available in the event.
It's worse than just abuse, though. It's neglect. The event creators are
neglecting the typed data fields in favor of providing untyped information
in the description field. The event creator is providing the information,
only in the wrong place--a place which makes the data useless. Garbage In,
Garbage Out. If only the event creator could be properly incented to provide
typed data and not provide conflicting data in an untyped description field.
My favorite solution is to disallow any markup in the description field. I
find the description field is often formatted in ways which are clear
attempts to provide structure, structure which is better housed in typed
data fields. Short of this radical solution...
I propose disallowing URLs in the description field. This is an 80% solution
with fairly low cost and nearly zero amortized cost.
If you take this course, I would also recommend that you sample your data to
determine what other kinds of links event creators are embedding into their
descriptions. This exercise may yield potential new fields you could add to
the event itself. Happily, XML is flexible, so adding fields (judiciously)
is not difficult. I suspect contact_email and phone_number would be helpful
fields. Also happily, your event data is transient, so clean-up does not
require back filling old data. Rather, it only requires ensuring the quality
of new data. As time passes, the quality of your event data will naturally
tend to improve.
I realize you're probably not looking for solution suggestions. After nine
years at Amazon.com, I've learned that getting advice from customers usually
only uncovers the customer's naivete. I do hope I've been more help that
hindrance.
Oh, by the way, I am developing for the iPhone. I'm using a
zooming/scrolling map I built myself since Apple and Google don't allow
developers to embed their map into applications and nobody else seems to
have one. Mapping is a core feature of my application, so this problem is
high on my priority list.
I look forward to hearing from you soon.
Cheers!
Jonathan
