Danny pointed out SemaView’s new calendar based product, Sherba, congratulating them on a …winning application of SemWeb technologies.
The company is using the iCal RDF Schema to create a windows-based application to manage and share event information through an interconnected calendaring system. My first reaction when I saw “window-based application” is to wince at the use of semantic web to what sounded like another Groove-like product that just happens to use RDF/XML for the data. Or does it?
According to the developer documentation, though the company’s application generates the RDF/XML data, it’s not hidden into the bowels of an application only accessible through archane, proprietary rituals or other perversions of openness. (And yes I’m including web services in this because to me, open means open — wide out there baby, just like this web page is. )
There are web services available, but more importantly to me, me being a person who believes that the semantic web is about data rather than applications, the product produces lovely RDF/XML files. Crawlable, open, plain view, accessible RDF/XML files.
Better, it gets better. Not only does the company produce the RDF/XML, it allows organizations that use the product to register their calendars in a global search directory called SherpaFind. Now you can search for events based on a set of parameters, view the calendar, download it, or best of all, directly access the RDF/XML for the calendar.
This is open. This is data within context, though Tim Berners-Lee hates that word . This is data that’s saying: excuse me little bots, sirs, kind sirs, but this data you’re slurping up isn’t just a mess of words waiting to be globally gulped and spit out in a bizarre search based on weights and links; it’s data that has some meaning to it. This data is calendaring data, and once you know that, you know that a lot.
Having said this, though, some of what I read leads me to think this isn’t as open as I thought at first glance. First, if I read this correctly, the Sherpa calendar information is centralized on the Sherpa servers. I’m assuming by this, again with just a first glance, that Semaview is providing the P2P cloud through which all of the clients interact in a manner extremely similiar to how Groove works. If this is true, I’ve said it before and will again — any hint of centralization within a distributed application is a point of weakness and vulnerability, the iron mountain hidden within the cloud.
Second, I can’t find the calendar RDF/XML out at the sites that use the product. There are no buttons at these sites that give me the RDF/XML directly. Additionally, trying variations of calendar.rdf isn’t returning anything either. Again, this is a fast preliminary read and I’ll correct my assumptions if I’m wrong — but is the only way to access the RDF/XML calendar information through SherpaFind? How do bots find this data?
Let’s compare Sherpa with that other popular use of RDF/XML: RSS. I generate an RSS 1.0 file that’s updated any time my weblog pages are updated. You can find it using multiple techniques, including searching for index.rdf files, following a link on my page or using RSS autodiscovery. You can find my site originally by me pinging a central server such as blo.gs. However, most of us find each other because we follow a link from another weblog. If we like what we read, we then subscribe to each other and use aggregators to keep up with updates. The golden gateway in this distributed application is through the links, rather than through an organization’s P2P cloud.
This is almost a pure P2P distributed application, enabled bya common vocabulary (RSS 1.0), serialized using a common syntax (RDF/XML), defined using a common data model, (RDF). Since it is dependent on the Internet and DNS, there’s an atom of iron in this cloud, but we can’t all be perfect. The only way to break this connection between the points is to take my site down (micro break), in which case there is no data anyway; or if we take the Internet down (macro break).
When you have a centralized cloud, like Groove’s, then you’re dependent on an organization to always and consistently provide this service. For Groove the product to work, Groove the company must continue to exist. If Groove no longer exists and the Groove cloud is no longer being maintained, hundreds, thousands, of connections to each other are lost.
The SemaView site mentions Sherpa Calendar in the context of Napster, as regards its functionality, except that calendaring information is shared rather than music. (We also have to assume the RIAA isn’t out to sue your butt if you use the application.) But Napster is based on the data being stored on the nodes — the end computers, not on the web. (Well, not directly on the wide open Web.) Is it, then, that the calendar data is stored on the individual PCs, only accessible through the Sherpa cloud? If this is so, then ingenous use of RDF/XML or not — this isn’t an application of the Sematic Web. This is just another application of web services.
(Though Tim B-L believes that the Semantic Web is based on functionality such as web services rather than data in context, I don’t agree. And many in the semantic web community wouldn’t, either. )
Without a closer look at how the product works, the documentation only tells me so much so my estimations of how this product functions overall is somewhat guesswork at this moment. When I have access to the product, I’ll do an update.
Page and comments are archived in the Wayback Machine