Wow! The BBC's web-research labs are taking The Archers to a new level.
Total respect, of course. The BBC is a major innovator in "old-media". (Aside. One reason the UK music scene is so good : 1-XTRA, a state-sponsored radio network which tracks and feeds the ever shifting fashions and inventions of London's pirate radio ecology.)
Update : of course there's a hint of SemWebishness about this (made explicit at the end of the blogpost) but nothing that stands out. The live-rolling soap format could be made to work equally well with the SynWeb, and there's no indication which they're actually using.
Showing posts with label synweb. Show all posts
Showing posts with label synweb. Show all posts
Thursday, September 11, 2008
Friday, November 23, 2007
Tim Berners Lee unconsciously pinpoints exactly what is wrong with the idea of a Semantic Web.
He thinks Semantics are a kind of "higher-level" of abstraction on top of existing syntactic web-technologies. So, for example, "documents about people" are somehow "higher-level" than mere documents.
But he's got things standing on their head.
"3 oranges" is not an abstraction on top of the number "3". In fact the idea "3" is an abstraction out of all the concrete cases like 3 oranges, 3 apples, 3 Pan Galactic Gargle Blasters etc.
The higher up the levels of abstraction you go, the fewer semantic commitments you make. That's why Alan Kay points out that higher-levels of abstraction are associated with later binding in programming languages. A dynamically typed language like Python only binds names to types at run-time, whereas a more statically bound language like Java binds them at compile time. Hence it's possible to write more generic routines in Python (ones that don't care whether they're working on integers, strings or Pan Galactic Gargle Blasters) than it is in Java.
The greatest "hits" of software : relational databases, spreadsheets, word-processors, blogs etc. are those which provide powerful syntactic abstractions (relational operations, pivot-tables, paragraphs, feeds etc.) while leaving the semantic commitments as late as possible. Usually up to the end-user or some specialist business analyst working in a domain specific language like SQL.
OTOH, often the worst (heaviest, clumsiest, hardest to change, least pleasant to use etc.) software is that which either through necessity or bad design is riddled with premature semantic commitments. Software which tries to bake "customer" in at a fundamental level and assumes "customer" has-one phone-number and has-one web-site, but didn't know that we'll be sending Tweets to customers about the status of their order, and so doesn't know that customers have Twitter ids.
This is the problem with the SemWeb ... it assumes we want applications that start from the semantics. But most of the time, we don't. We want powerful syntactic abstractions over which we layer our own meaning.
He thinks Semantics are a kind of "higher-level" of abstraction on top of existing syntactic web-technologies. So, for example, "documents about people" are somehow "higher-level" than mere documents.
But he's got things standing on their head.
"3 oranges" is not an abstraction on top of the number "3". In fact the idea "3" is an abstraction out of all the concrete cases like 3 oranges, 3 apples, 3 Pan Galactic Gargle Blasters etc.
The higher up the levels of abstraction you go, the fewer semantic commitments you make. That's why Alan Kay points out that higher-levels of abstraction are associated with later binding in programming languages. A dynamically typed language like Python only binds names to types at run-time, whereas a more statically bound language like Java binds them at compile time. Hence it's possible to write more generic routines in Python (ones that don't care whether they're working on integers, strings or Pan Galactic Gargle Blasters) than it is in Java.
The greatest "hits" of software : relational databases, spreadsheets, word-processors, blogs etc. are those which provide powerful syntactic abstractions (relational operations, pivot-tables, paragraphs, feeds etc.) while leaving the semantic commitments as late as possible. Usually up to the end-user or some specialist business analyst working in a domain specific language like SQL.
OTOH, often the worst (heaviest, clumsiest, hardest to change, least pleasant to use etc.) software is that which either through necessity or bad design is riddled with premature semantic commitments. Software which tries to bake "customer" in at a fundamental level and assumes "customer" has-one phone-number and has-one web-site, but didn't know that we'll be sending Tweets to customers about the status of their order, and so doesn't know that customers have Twitter ids.
This is the problem with the SemWeb ... it assumes we want applications that start from the semantics. But most of the time, we don't. We want powerful syntactic abstractions over which we layer our own meaning.
Subscribe to:
Posts (Atom)