If you run a search engine, here's an idea for free.
I like being able to search the web - for web pages, for map information, for local information. It's become a default action for me, I keep wireless PCs in all the rooms of the house, and my phone has Google bookmarked and ready to use wherever I am. I can concoct search queries that get me to the information I want quickly and easily, avoiding paid search results and catalogue aggregation sites. Boolean search logic is just another language now. However, sometimes I'd like to search by date.
This is where the utopia of the search engine suddenly comes to a screaming halt.
Yesterday
marypcb and I were planning a US trip (which is starting to look like it will fill most of March). As we were using the British Airways sale to book tickets, flights were limited - and the longer we stayed, the better the deal. So I tried to see if there were any interesting events we could visit whilst we were over.
And that's where everything fell apart.
Could I get a search term to let me know if there where any conferences we could visit? No matter how I tweaked the search terms I kept getting the same list that I had to page through to track down the information I needed. I couldn't sort it, filter it, or even tune the search.
The trouble is: search engines don't really like you trying to look for date ranges. A search term like "technology conference march 2006" doesn't really mean anything to Google. You'll get lots of results, but nothing to help you order results by date or by location. Date-based searching is as important as location-based search (and the two combine together very well indeed). As more and more people use, and rely on, search engines, the queries they use will become more and more complex.
Of course there are issues with the semantics of date (let alone with date formatting). Are you asking for web pages created on a certain date, or containing information about that date? Are you specifying a date range, or are you looking for a specific date? These are complex questions - and I wonder if they're the reason why the oft-rumoured Google Calendar is yet to appear.
Microformats are one approach that could help here. Technorati has defined hCalendar as a web page-embedded XML-tagged equivalent for the familiar iCalendar format, which would allow search engines to build arrays of calendar data for search that could be linked to web content. Alternatively iCalendar-driven calendars are appearing all over the web. Apple's iCal uses the format to publish web calendars to .Mac , as does Outlook and the new calendar tool in Windows Vista - and there are plenty of open source iCalendar servers, as well as desktop calendaring applications that can handle iCalendar data.
What's to stop these tools being used to ping a date registry when calendar information is posted in a public space?
So, Apple, Microsoft, Technorati, Google, FAST, Yahoo! and MSN, get together and give us time-based search. The UI doesn't really matter (though a calendar grid would work really well for drill down), as long as we can sort results by date...
I like being able to search the web - for web pages, for map information, for local information. It's become a default action for me, I keep wireless PCs in all the rooms of the house, and my phone has Google bookmarked and ready to use wherever I am. I can concoct search queries that get me to the information I want quickly and easily, avoiding paid search results and catalogue aggregation sites. Boolean search logic is just another language now. However, sometimes I'd like to search by date.
This is where the utopia of the search engine suddenly comes to a screaming halt.
Yesterday
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
And that's where everything fell apart.
Could I get a search term to let me know if there where any conferences we could visit? No matter how I tweaked the search terms I kept getting the same list that I had to page through to track down the information I needed. I couldn't sort it, filter it, or even tune the search.
The trouble is: search engines don't really like you trying to look for date ranges. A search term like "technology conference march 2006" doesn't really mean anything to Google. You'll get lots of results, but nothing to help you order results by date or by location. Date-based searching is as important as location-based search (and the two combine together very well indeed). As more and more people use, and rely on, search engines, the queries they use will become more and more complex.
Of course there are issues with the semantics of date (let alone with date formatting). Are you asking for web pages created on a certain date, or containing information about that date? Are you specifying a date range, or are you looking for a specific date? These are complex questions - and I wonder if they're the reason why the oft-rumoured Google Calendar is yet to appear.
Microformats are one approach that could help here. Technorati has defined hCalendar as a web page-embedded XML-tagged equivalent for the familiar iCalendar format, which would allow search engines to build arrays of calendar data for search that could be linked to web content. Alternatively iCalendar-driven calendars are appearing all over the web. Apple's iCal uses the format to publish web calendars to .Mac , as does Outlook and the new calendar tool in Windows Vista - and there are plenty of open source iCalendar servers, as well as desktop calendaring applications that can handle iCalendar data.
What's to stop these tools being used to ping a date registry when calendar information is posted in a public space?
So, Apple, Microsoft, Technorati, Google, FAST, Yahoo! and MSN, get together and give us time-based search. The UI doesn't really matter (though a calendar grid would work really well for drill down), as long as we can sort results by date...
(no subject)
(no subject)
As to the date formats, then they're out there. Been out there for years. Doesn't need anything so tightly application-bound as vCal or iCalendar either (and if you think XML is the solution, then you've missed the point).
This whole issue (technically) is so 2001 8-( We fixed this one ages ago - start using it, guys.
(no subject)
(no subject)
(no subject)
(no subject)
It's also interesting to note how Upcoming handles events.
(no subject)
The most common format for event data seems to be iCal, but that has the disadvantage of being none too pleasant to parse. There's an RDF schema based on iCal which suffers the same conceptual problems as iCal, but with the added advantage/disadvantage of RDF syntax, depending on who you talk to (I'm firmly in the pro-RDF camp, and even I think that RDF-calendar is a bit awkward). Failing that, there are the microformats such as hCal, which again is essentially another syntax for iCal, but one which has been shoehorned into XHTML.
(no subject)
http://upcoming.org/
Upcoming seems to be a kind of flickr for events - down to being snapped up by Yahoo. I wonder if date is going to be 2006's location? I don't know if their event badges are using a microformat... But there's no Date view: while you can see what's popular, what's on in SF or LA, what your friends have organised, you can't see what's on Tuesday next until you drill down to a specific location.
And the step beyond - being able to get things into my local calendar from a search other than copy, create event, paste!
(no subject)
Both, ideally. I posted on this sometime last year
What's to stop these tools being used to ping a date registry when calendar information is posted in a public space?
An online counterpart to the atomic clock?
So, Apple, Microsoft, Technorati, Google, FAST, Yahoo! and MSN, get together and give us time-based search. The UI doesn't really matter (though a calendar grid would work really well for drill down), as long as we can sort results by date...
Hear hear.
(no subject)
(no subject)
As far as I'm aware, most SW researchers who are actually addressing this problem are doing much the same as we are (we being my my research group in Southampton); we have a simple ontology (based in part around the dc:coverage predicate) that allows us to define the period during which the triples in a given RDF graph are valid. Graph-level assertions, which are usually made by making statements about the RDF/XML file that contains the serialisation of the graph, are generally thought preferable to triple-level assertions (in which RDF reification is used to provide a target for the validity assertions).
(no subject)
(no subject)
An alternative approach is to search for a search engine that might do what you want. For instance, "conference search engine" turned up...
http://www.allconferences.com/
Now if only its advanced search didn't seem to behave in a random manner... :-)