The path from specificity to usefulness
Jan 8th, 2007 by Phil Dawes
I tried to comment on Seth’s post, but I think the comments on his blog are a bit broken at the moment (the capcha question wasn’t rendering, so I couldn’t answer it!). I guess I’ll trackback instead:
The path from specificity to usefulness that Seth describes was exactly the trip I took attempting to implement semantic web approaches at work to assist with managing IT operations info (which was stored in various silos). I started off with RDF and built a store which used some OWL rules to connect the data from the various sources. This proved cumbersome and difficult - other people found it quite a hurdle trying to understand RDF, and the same URIs got used to mean subtly different things (e.g. IT application vs project).
After a year and a half of evolving the system the best solution ended up being to just index triples of words. Vaguer than URIs, but easier to harvest and match from databases. Since humans write the queries, it turned out that the vagueness wasn’t a problem at all.
Universal Specificity (such as is required by URIs/RDF) just doesn’t seem to scale very well in my experience.
Have you read Do Androids Dream of Electric Sheep?
Maybe you couldn’t see the capcha by design…
The thing that is tricky about all of this, is that a URI sure enough identifies a singular resource. However, that Resource can belong to an infinite amount of classes. That is, the Resource can mean many different things to many different people. This is both a strength and a weakness, and leads to much trickiness when implementing RDF.
The more vague a Resource is defined, the more useful it is, because people don’t get caught up in over thinking, “Do I match the intended meanings?”
So, if RDF is to work, implementers have to allow for mechanisms to help humans deal with the many interpretations of the Resources those URIs identify.