Mike Linksvayer

This music had every cell and fiber in my body on heavy sizzle mode.

Thurston Moore on mixtapes, could be describing me listening to early Sonic Youth or one of my many ecstasy-inducing 120 minute cassettes that I’m mostly afraid to touch, really need to digitize. Yes, Moore relates it all to MP3, P2P, etc., sounding like he’s from the EFF:

Once again, we’re being told that home taping (in the form of ripping and burning) is killing music. But it’s not: It simply exists as a nod to the true love and ego involved in sharing music with friends and lovers. Trying to control music sharing - by shutting down P2P sites or MP3 blogs or BitTorrent or whatever other technology comes along - is like trying to control an affair of the heart. Nothing will stop it.

[Via Lucas Gonze.]

I’d like little more right now than to have Sonic Youth or one of Moore’s many avant projects to release some crack under a Creative Commons license. Had they already you could maybe find it via the just released Yahoo! Search for Creative Commons. (How’s that for a lame segue?)

“The Semantic Web: Promising Future or Utter Failure”, the panel I took part in at SXSW shed little light on the topic. Each panelist (including me) brought their own idiosyncratic views to bear and largely talked past each other. The overall SXSW interactive crowd seemed to tend toward web designers and web marketers, not sure about the audience for this panel. Some people, e.g., Chet Campbell, and others in person, apparently left with the impression that all of the panelists agreed that the semantic web is an utter failure (not my view at all).

Sam Felder and Josh Knowles have posted loose transcripts and Christian Bradford a photo of the panel.

The approximate (with links and a few small corrections) text of my introductory statement follows. I got a few laughs.

I want to draw some parallels between semantic web technologies and artificial intelligence and between semantic web technologies and Java.

AI was going to produce intelligent machines. It didn’t and since the late 80s we’ve been in an “AI winter.” That’s nearly twenty years, so web people who suffered and whined in 2001-3, your cup is more than half full. Anyway since then AI techniques have been used in all sorts of products, but once deployed the technology isn’t seen as AI. I mean, where are the conscious robots?

Semantic web technologies have a shorter history, but may play out similarly: widely used but not recognized as such. Machine “agents” aren’t inferring a perfect date for me from my FOAF profile. Or something. This problem is magnified because there’s a loose connection between sematnic web grand visions and AI. People work on both at MIT after all.

Now Java. Applets were going to revolutionize the web. In 1996! Applets didn’t work very well, but lots of people learned Java and it runs out Java is a pretty good solution on the server side. Java is hugely successful as the 21st century’s COBOL. Need some “business logic?” You won’t get fired for implementing it in Java, preferably using JDBC, JSP, JMX, JMS, EJB, JAXB, JDO and other buzzword-compliant APIs.

Semantic web technologies may be following a similar path. Utter failure to live up to initial hype in a sexy domain, but succeeding in the enterprise where the money is anyway. I haven’t heard anyone utter the word enterprise at this conference, so I won’t repeat it.

It turns out that semantic web technologies are really useful for data integration when you have heterogenous data, as many people do these days. Just one example: Oracle will support a “Network Data Model” in the next release of their database. That may sound like a throwback if you know database history, but it basically means explicit support for storing and querying graphs, which are the data model of RDF and the semantic web.

If you talk to a few of the people trying to build intelligent machines today, who may use the term Artificial General Intelligence to distinguish themselves from AI, you may get a feeling that AI research hasn’t really moved us toward the goal of building an AGI.

Despite Java’s success on the server it is no closer to being important on the web client than it was in 1996. It is probably further. If what you care about is sexy web browser deployment, all Java’s server success has accomplished is to keep the language alive.

Semantic web technologies may be different. Usefulness in behind the scenes data integration may help these technologies gain traction on the web. Why? Because for someone trying to make use of data on the web, the web is one huge heterogenous data integration problem.

An example of a project that uses RDF for data integration that you can see is mSpace. You can read a a paper about how they use RDF inside the application, but it won’t be obvious to an end user that they’re a semantic web technologies application, and that’s as it should be.

One interesting thing about mSpace is that they’re using a classical music ontology developed by someone else and found on SchemaWeb. SchemaWeb is a good place to look for semantic web schemas that can be reused in your project. Similarly, rdfdata.org is a good place to look for RDF datasets to reuse. There are dozens of schemas and datasets listed on these sites contributed by people and organizations around the world, covering beer, wine, vegetarian food, and lots of stuff you don’t put in your mouth.

I intended to close my statement with a preemption of the claim that use of semantic web technologies mandates hashing everything out in committees before deployment (wrong), but I trailed off with something I don’t recall. The committee myth came up again during the discussion anyway.

Perhaps I should’ve stolen Eric Miller’s The Semantic Web is Here slides.

At SXSW today Eric Meyer gave a talk on Emergent Semantics. He humorously described emergent as a fancy way of saying grassroots, groundup (from the bottom or like ground beef), or evolutionary. The talk was about adding rel attributes to XHTML <a> elements, or the lowercase semantic web, or Semantic XHTML, of which I am a fan.

Unfortunately Eric made some incorrect statements about the uppercase Semantic Web, or RDF/RDFS/OWL, of which I am also a fan. First, he implied that the lowercase semantic web is to the Semantic Web as evolution is to intelligent design, the current last redoubt of apolgists for theism.

Very much related to this analogy, Eric stressed that use of Semantic XHTML is ad hoc and easy to experiment with, while the Semantic Web requires getting a committee to agree on an ontology.

Not true! Just using rel="foo" is equivalent to using a http://example.com/foo RDF property (though the meaning of the RDF property is better defined — it applies to a URI, while the application of the implicit rel property is loose).

In the case of more complex formats, an individual can define something like hCard (lowercase) or vCard-RDF (uppercase).

No committee approval is required in any of the above examples. vCard-RDF happens to have been submitted to the W3C, but doing so is absolutely not required, as I know from personal experience at Bitzi and Creative Commons, both of which use RDF never approved by committee.

At best there may be a tendency for people using RDF to try to get consensus on vocabulary before deployment while there may be a tendency for people using Semantic XHTML to throw keywords at the wall and see if they stick (however, Eric mentioned that the XFN (lowercase) core group debated whether to include me in the first release of their spec). Neither technology mandates either approach. If either of these tendencies to exist, they must be cultural.

I think there is value in the ad hoc culture and more importantly closeness of Semantic XHTML assertions to human readable markup of the lowercase semantic web and the rigor of the uppercase Semantic Web.

It may be useful to transform a rel="" assertions to RDF assertions via GRDDL or a GRDDL-inspired XMDP transformation.

I will find it useful to bring RDF into XHTML, probably via RDF/A, which I like to call Hard Core Semantic XHTML.

Marc Canter as usual expressed himself from the audience (and on his blog). Among other things Marc asked why Eric didn’t use the word metadata. I don’t recall Eric’s answer, but I commend him for not using the term. I’d be even happier if we could avoid the word semantic as well. Those are rants for another time.

Addendum: I didn’t make it to the session this afternoon, but Tantek Çelik’s slides for The Elements of Meaningful XHTML are an excellent introduction to Semantic XHTML for anyone familiar with [X]HTML.

Addendum 20050314: Eric Meyer has posted his slides.

I’m in Austin now through Monday for SXSW and in San Diego Tuesday through Thursday for Etech. I’m sad that I won’t be around for any music showcases this year and that I have to leave Austin for one of my less favorite places, but Etech is the better conference.

I’m helping Matt Haughey with a SXSW panel, The Semantic Web: Promising Future or Utter Failure (I’ll be the SemWeb technologies advocate) and an Etech session, Remixing Culture with RDF: Running a Semantic Web Search in the Wild.

Creative Commons will have other events and a party at SXSW.

CodeCon is 5/5 today.

The Ultra Gleeper. A personal web page recommendation system. Promise of collaborative filtering unfulfilled, in dark ages since Firefly was acquired and shut down in the mid-90s. Presenter believes we’re about to experience a renaissance in recommendation systems, citing Audiocrobbler recommendations (I would link to mine, but personal recommendations seem to have disappeared since last time I looked; my audioscrobbler page) as a useful example (I have found no automated music recommendation system useful) and blogs as a use case for recommendations (I have far too much very high quality manually discovered reading material, including blogs, to desire automated recommendations for more and I don’t see collaborative filtering as a useful means of prioritizing my lists). The Ultra Gleeper crawls pages you link to, treating links as positive ratings, pages that link to you (via Technorati CosmosQuery and Google API), presents suggested pages to rate in a web interface. Uses a number of tricks to avoid showing obvious recommendations (does not recommend pages that are two popular) and pages you’ve already seen (including those linked to in feeds you subscribe to). Some problems faced by typical recommendation systems (new users get crummy recommendations until they enter lots of data, early adopters get doubly crummy recommendations due to lack of existing data to correlate with) obviated by bootstrapping from data in your posts and subscriptions. I suppose if lots of people run something like Gleeper robot traffic increases, more people complain about syndication bandwidth-like problems (I’m skeptical about this being a major problem). I don’t see lots of people running Gleepers as automated recommendation systems are still fairly useless and will remain so for a long time. Interesting software and presentation nonetheless.

H2O. Primarily a discussion system tuned to facilitate professor-assigned discussions. Posts may be embargoed and professor may assign course participants specific messages or other participants to respond to. Discussions may include participants from multiple courses, e.g., to facilitate a MIT engineering-Harvard law exchange. Anyone may register at H2O and create own group, acting as professor for created group. Some of the constraints that may be iposed by H2O are often raised in mailing list meta discussions following flame wars, in particular posting delays. I dislike web forums but may have to try H2O out. Another aspect of H2O is syllabus management and sharing, which is interesting largely because syllabi are typically well hidden. Professors in the same school of the same university may not be aware of what each other are teaching.

Jakarta Feedparser. Kevin Burton gave a good overview of syndication and related standards and the many challenges of dealing with feeds in the wild, which are broken in every conceivable way. Claims SAX (event) based Jakarta FeedParser is an order of magnitude faster than DOM (tree) based parsers. Nothing new to me, but very useful code.

MAPPR. Uses Flickr tags, GNS to divine geographic location of photos. REST web services modeled on Flickr’s own. Flash front end, which you could spend many hours playing with.

Photospace. Personal image annotation and search service, focus on geolocation. Functionality available as library, web fron end provided. Photospace publishes RDF which may be consumed by RDFMapper.

Note above two personal web applications that crawl or use services of other sites (The Ultra Gleeper is the stronger example of this). I bet we’ll see many more of increasing sophistication enabled by ready and easily deployable software infrastructure like Jakarta FeedParser, Lucene, SQLite and many others. A personal social networking application is an obvious candidate. Add in user hosted or controlled authentication (e.g., LID, perhaps idcommons) …

Yesterday.

“Do not credit this link” is a useful assertion that cannot be gleaned from surrounding content.

Thus, rel="nofollow" is a good if old idea. At least one of my two search predictions for 2005 is already coming true.

Creator assigned keywords or “tags” on the other hand, strike me as a contemporary implementation of HTML meta description tags, which failed because they placed a burden on good webmasters (classification is hard) and presented an open field for spammers, who tag[ged] their pages making a hard sell for whatever with completely unrelated keywords.

Global classification strikes me as a case in which Google is right — metadata inferred from content beats explicit, manual metadata when it comes to categorization. From the Peter Norvig (Google Director of Search Quality) interview I cited:

This is a Google News page from last night, and what we’ve done here is apply clustering technology to put the news stories together in categories, so you see the top story there about Blair, and there’re 658 related stories that we’ve clustered together.

Now imagine what it would be like if instead of using our algorithms we relied on the news suppliers to put in all the right metadata and label their stories the way they wanted to. “Is my story a story that’s going to be buried on page 20, or is it a top story? I’ll put my metadata in. Are the people I’m talking about terrorists or freedom fighters? What’s the definition of patriot? What’s the definition of marriage?”

Folksonomies are great in limited domains, thus far most famously for organizing and sharing bookmarks (decentralize using same technology as Technorati’s self-tagging) and organizing photos.

Keyword tagging is also a lightweight way to provide navigation for a website. I might categorize more posts on this weblog if I could do so in a similarly lightweight manner (now I have to create categories via an interface separate from posting). Haven’t I come right back to the creator-assigned keywords that I criticized above? No, there’s a subtle but very important difference: metadata as a side effect of useful work versus metadata as spammy make work.

Google’s director of search quality bashes manual ontologies, with much justification.

However, his attempt to paint successful ontologies into a tiny niche doesn’t exactly work:

The best place where ontologies will work is when you have an oligarchy of consumers who can force the providers to play the game. Something like the auto parts industry, where the auto manufacturers can get together and say, “Everybody who wants to sell to us do this.” They can do that because there’s only a couple of them. In other industries, if there’s one major player, then they don’t want to play the game because they don’t want everybody else to catch up. And if there’s too many minor players, then it’s hard for them to get together.

Aren’t search engines and browsers in a sense oligopolistic (actually oligopsonistic) consumers of web content? There are only a few of each that matter anyway.

Barring interest from Google, Microsoft, Mozilla, and Yahoo! there may be oligopsonists (or monopsonists who want their standards adopted) in niches that can drive metadata adoption in their niches.

[Via Andrew Newman.]

Nathan Yergler just cut ccPublisher 1.0, a Windows/Mac/Linux desktop app that helps you license, tag, and distribute your audio and video works. I’m very biased, but I think it’d be a pretty neat little application even if it weren’t Creative Commons centric.

• It’s written in Python with a wxPython UI, but is distributed as a native windows installer or Mac disk image with no dependencies. Install and run like any other program on your platform, no implementation leakage. Drag’n'drop works.
• Also invisible to the end user, it uses the Internet Archive’s XML contribution interface, ftp and CC’s nascent web services.
• RDF metadata is generated, hidden from the user if published at IA, or available for self-publishing, ties into CC’s search and P2P strategies.

Python and friends did most of the work, but the 90/10-10/90 rule applied (making a cross platform app work well still isn’t trivial, integration is always messy, and anything involving ID3v2 sucks). Props to Nathan.

Version 2 will be much slicker, support more media types, and be extensible for use by other data repositories.

Addendum 2005-01-12: Check out Nathan’s 1.0 post mortem and 2.0 preview.

Many of John “Searchblog” Battelle’s predictions for 2005 seem like near certainties, e.g., a fractious year for the blogosphere and trouble for those who expect major revenues from blogging.

Two trends I hope 2005 proves that Battelle’s predictions missed:

Metadata-enhanced search. Will be ad hoc and pragmatic, pulling useful bits from private sources and people following officious Semantic Web and lowercase semantic web practices.

Proliferation of niche web scale search engines. Anyone can be a small-scale google, crawling the portions of the web cared about and offering search options specific to a niche. The requisite hardware and bandwidth are supercheap and the Nutch open source search engine makes implementation trivial.

The Creative Commons search engine is a harbinger of both trends.

Battelle’s look ahead spans the web, not just web search. Possibly the biggest trend missing from his list is the rise of weblications. Egads, I have to learn DHTML, and it isn’t 1997!

A few of my near certainties: lots of desktop search innovation, very slow progress on making multimedia work with the web and usable security, open source slogs toward world domination, and most things get cheaper and more efficient.

Continuation of MusicBrainz Discovery (I).

One notable thing about MusicBrainz is that Rob Kaye and a small number of core developers and supporters have pursued a consistent vision for roughly six years with very little funding or even understanding outside this small group. It isn’t easy to really “get” MusicBrainz (I think it took me two years), though I think that at some point in the next few years everyone will “get” MusicBrainz more or less all at once.

If you’re a geek it’s hard not to get hung up on MusicBrainz use of acoustic fingerprint-based technology. Acoustic fingerprinting is fragile in three ways — it is subject to false positives and false negatives, there is no open source implementation of the concept, and the technology MusicBrainz uses, Relatable TRM, is proprietary and requires a centralized server. Indeed, many of the technology questions at Tuesday’s music metadata panel concerned acoustic fingerprints.

It is important to understand that while MusicBrainz uses acoustic fingerprints, it does not rely on them. TRM matching is just one mechanism for track identification. File metadata included in (e.g., ID3 tags) or with (filename) the file can and I believe are used to match existing records, as could track duration and file hashes (see if Bitzi or a P2P network has any metadata for the file in question). Additionally, file identification is only one component of MusicBrainz.

If you’re not a geek, you won’t notice acoustic fingerprints, because you wouldn’t, and because you’re not likely to get that far. So what the heck does MusicBrainz do? Here’s an attempt:

• MusicBrainz can organize your music collection. Download the tagger.
• MusicBrainz uniquely identifies artists, albums, and songs, facilitating rich and precise music applications, all on a level playing field.
  • Not at all speculative potential: include a MusicBrainz song identifier in a blog post, cover art (with your Amazon referrer of course) automagically appears in blog post, blog aggregator publishes top n lists and personalized recommendations.
  • Another: publish a playlist of MusicBrainz identifiers and others can recreate the experience so defined with no file transfer involved.
  • There are several others, some that could be offered by MusicBrainz itself, outlined in MusicBrainz tomorrow. I have to quote one because it’s fun:
    

    Music Genealogy: MusicBrainz may keep track of which artists/performers/engineers contributed to a piece of music, and when these contributions took place. Combining this contribution data with data on how artists influenced each other will create a genealogy of modern music. Imagine being able to track Britney Spears back to Beethoven!

• The MusicBrainz database, created by the community, will remain free, unlike others.

Having been around for awhile, MusicBrainz has run into many of the technical and social problems inherent in music metadata and an evolving community website, and produced much good documentation on solutions, realized and potential. Here’s a sampling:

• Data License Issues and the solution.
• Style Guidelines — you wouldn’t imagine how hard good capitalization rules are, for starters. Ugh. Don’t even attempt to think about Classical metadata!
• Cross-platform desktop app, using wxPython, same as Creative Commons.
• How to identify a compact disc.
• Tracking relationships among tracks, albums, artists, and much more.
• Survival of the fittest and steps towards survival of the fittest — how do you take some wiki lessons and apply to a large and highly structured database and featureset?
• MusicBrainz Metadata Initiative — web services and RDF, hand rolled.
• MusicBrainz Non-Profit White Paper, already linked above this list is very interesting on several subjects.
• How the server works.
• Everyone loves stats.

By the way, as of Wednesday MusicBrainz has a blog.

Earlier this evening I gave a brief introduction (slides PDF) to MusicBrainz at SDForum’s Emerging Technology SIG meeting on music metadata in the stead of MusicBrainz founder and leader Rob Kaye, who couldn’t make it up to Palo Alto. (I’m fairly familiar with MusicBrainz, having worked with Rob at Bitzi and getting updates when we cross paths in this small world.)

If I could pick a theme for the meeting (which included two other very interesting speakers — Stephen Bronstein of the Independent Online Distribution Alliance and David Marks of Loomia), and for recent months in general, it would be that in case you haven’t noticed, it’s clearly now a discovery problem, not a delivery problem.

SIG leader William Grosso led off with some quotes from the much-discussed Wired magazine article The Long Tail, which seems to have captured this zeitgeist. (Grosso also had a novel to me presentation technique — a slideshow of potentially relevant slides plays while he speaks, and if a slide happens to be relevant to the current sentence, he uses the slide to augment the point. Is there a name for this?)

Obviously there was tremendous interest in Creative Commons in this context, and several people seemed to be happy to learn of CC’s search engine and the great services and products offered by the Internet Archive (free hosting for CC-licensed audio and video, built in format conversion), Magnatune (all CC-licensed music label) and more.

Unfortunately in the eleven years I’ve been in the SF bay area I only definitively recall attending two previous SDForum events — a 1994 talk by Atari Jaguar developers in San Jose and in 2001 an evening with Phil Zimmermann in San Francisco (I suspect others who were there would deem the “an evening with” cliche appropriate in this case). This evening’s meeting was a total geekfest. I hung around for well over an hour commiserating on all manner of software development topics (I think that’s what “SD” stands for) with a number of hardcore geeks (no whatever-Dilbert’s-boss’s-name-is there) while two guys were lauging their asses off whiteboarding issues with Unicode encoding (as far as I could tell). I’ll have to go back.

More about what I’ve learned about MusicBrainz over the years and in preparing for the evening in a future post.

Update: part 2

Yesterday on the Creative Commons weblog:

Today we announce a search engine prototype exclusively for finding Creative Commons licensed and public domain works on the web.

Indexing only pages with valid Creative Commons metadata allows the search engine to display a visual indicator of the conditions under which works may be used as well as offer the option to limit results to works available licenses allowing for derivatives or commercial use.

This prototype partially addresses one of our tech challenges. It still needs lots of work. If you’re an interested developer you can obtain the code and submit bugs via the cctools project at SourceForge. The code is GNU GPL licensed and builds in part upon Nathan Yergler’s ccRdf library.

We also have an outstanding challenge to commercial search engines to build support for Creative Commons-enhanced searches.

And it hasn’t melted down yet.

Ben Adida wrote most of the code that needed to be written in Python (not much — PostgreSQL with tsearch2 full-text indexing does all of the heavy lifting). Former government employee Justin Palmer wrote an earlier prototype in AOLserver/Tcl, also using PG/tsearch2. (Turns out we needed the flexibility of running under Apache. I’ll miss AOLserver/Tcl when I last touch it, but I’ll also be glad to be rid of it.) I did a PHP hack job on the front end, and Matt Haughey made it look good (for end users, not code readers) in a matter of minutes.

Although everything possible sucks about this implementation, it is already a valuable tool for finding CC-licensed and public domain content — stuff you can reuse with permission already granted. Neeru Paharia was the visionary here, seeing that it would be valuable even if it sucked in every way technically.

Stephen Downes is exactly right about the long term goal:

Of course, this is only a step - such a search engine would not be useful for many purposed; copyright information needs, in the long run, to define a search field or a type of search, not a whole search engine.

With great justification major search enginges have ignored pure metadata for a long time, at least five years. Pure metadata, with no visibility, is nearly universally ill-maintained or fraudulent. I hope that this Creative Commons prototype inspires some people at major search engines to think again about metadata, but I think semantic HTML is what will finally prove useful to such folks, in no small part because it isn’t pure metadata. I’ll post on incremental semantic search engine features in the near future.

Tantek �elik comments on Creative Commons use of rel="license", citing my small-s semantic web and CC post to cc-metadata (reproduced below).

I agree with Tantek’s comments, though I wouldn’t advise removing admittedly ugly and potentially redundant RDF-in-HTML-comments, at least not until mozCC and ccRdf and consequently some dependent code go case insensitive.

There are currently at least two Creative Commons metadata cases where a simple rel="license" attribute won’t do, requiring RDF:

• The current resource needs to make statements about other resources, e.g., when those resources aren’t adept at carrying their own metadata or staying in one place.
• One wants to include rich metadata, for example concerning a creator or rights holder, though that particular example I suppose cries out for rel="tipjar" where no further requirements are present.

In my view, metadata-enabled web tools will do well to include a RDF model layer, whether the statements be gleaned from semantic [X]HTML, parsed from human language, or mainlined from some RDF encoding, and whatever the tool’s internal knowledge representation. Content creators will do well to produce the simplest, most utilitarian metadata possible.

I’m turning a bit sour on the phrase “lowercase semantic web”. I like semantic [X]HTML. I like RDF. All in the service of our near-term goals. All in the service of the Semantic Web, which will surely be a superset of the RDF web. I dig real world semantics in any case.

As I mentioned
<http://lists.ibiblio.org/pipermail/cc-metadata/2003-December/000243.html>
I find "semantic HTML" very interesting — it keeps the metadata close
to the presentation, militating against "metacrap" and can be used to
populate the big-S Semantic Web through RDF generation.

Since then the RDF-in-XHTML proposal that builds on semantic HTML has
moved ahead and generalized, see <http://www.w3.org/2004/01/rdxh/spec>
"Gleaning Resource Descriptions from Dialects of Languages" is a pretty
good description.

Also, Kevin Marks and Tantek Celik headed up a very nice BoF at Etech
<http://wiki.oreillynet.com/etech/hosted.conf?RealWorldSemantics> in
which they discussed current small-semantic web implementations. See
that URL for some good links.

Largely, people are using the "rel" attribute of "a" elements
<http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_a>
to describe "the relationship from the current document to the URI
referred to by the element. The value of this attribute is a
space-separated list of link types."

<http://www.w3.org/TR/xhtml2/mod-attribute-collections.html#col_Hypertext>
(I can’t find the equivalent documentation for XHTML1, but rel is
supported, per the DTD above).

A neat thing on the presentation side is that CSS selectors can actually
change the document rendering based on rel attributes — making the
metadata not just close to the presentation, but part of it.

Anyway, a rel attribute on anchors removes the big problem with assuming
that a link to a license indicates that a page is available under that
license — the page could be linking to the license for any reason. <a
rel="license" href="http://creativecommons.org/licenses/by/1.0/"/> on
the other hand, is no more ambiguous than the following RDF snippet

<Work about="">
<license rdf:resource="http://creativecommons.org/licenses/by/1.0/"/>
</Work>

and can be used to generate the same.

The upshot is that I’m planning to recommend adding a rel="license"
attribute to links to CC licenses where the license applies to the
current page, have <http://creativecommons.org/license/> spit that out,
and encourage other apps to support the same.

Note that this is all entirely complementary with RDF. All apps should
continue to use/generate/support RDF, and RDF is required for making
license (or any metadata) statements about resources other than the
enclosing one.

Pleasant Blogger says “Bookcrossing + Orkut + Bitzi + HotOrNot = Mediachest“.

I don’t think addition is the correct operation. Perhaps we could say all of

• Bookcrossing ∩ Mediachest ≠ ∅
• Orkut ∩ Mediachest ≠ ∅
• Bitzi ∩ Mediachest ≠ ∅
• HotOrNot ∩ Mediachest ≠ ∅

or something more interesting if I actually knew set theory and notation.

Seriously though, lots of people realize that social networks can facilitate navigation, discovery, trust, filtering, communication and the like in many domains. Will people move on from sites that encourage building lists of “friends” for the sake of building such lists (and dating, I hear) to sites that use social networks to enhance other functions a la Mediachest or will the likes of Friendster and Orkut add more utility? Probably something else. Consider that

• Orkut has only scratched the surface of what a pure social networking service could offer. There are no collaborative filtering or recommendation features for starters. I don’t think Orkut is near an 80/20 sweet spot, or wherever diminishing returns set in for a pure social networking site.
• Sites with huge existing memberships haven’t added social networking to their offerings. Friends.yahoo.com does not exist.
• I’m forgetting stuff, but not the decentralized path. See FOAF and XFN. Atop which every value-add you can imagine (a miniscule subset of the total) will be built in the semi-near future, like by 2009.

Bitzi has had a very simple social network feature since May, 2001, “interesting bitizens”. Mine (and those interested in me) are currently listed on the right side of my bitizen page. We still haven’t built any features using these relationships, apart from an ignored popularity contest. Eventually. Before 2009.

Experimenting with vote links:

Goodbye, WP, join the LAT in the infinite unread bin.

Points mentioned at the Etech Creative Commons participant session (it’s a BoF!):

One Year Launch Anniversary

Watch Reticulum Rex AKA Remix Culture for an update.

License Versioning

• License Versioning Public Review
• 2.0 License Draft
• Discussion at cc-licenses
• Warranty protocol metadata proposal

International Commons

iCommons is porting licenses to multiple jurisdictions.

Content

• Get Content
• Common Content (directory)
• Internet Archive (free hosting)
• Demo/hack via AlltheWeb and prototype below

New (and newly packaged) Licenses

• [L]GPL packaging available
• Sampling
• Education
• Developing Nations

Technology

• CC technology site
• Discussion at cc-metadata

Standards

• Dublin Core improved usage (DC2003 presentation)
• Using foaf:Agent. Tipjar?
• W3C involvement (beyond a RDF testimonial!)
• SMIL and SVG

Technology Challenges

The list

Hero Nathan Yergler, who created:

• ccValidator
• ccRdf
• mozCC

POTOTYPE RDF-enhanced Creative Commons search