WARNING: this is a collection of ill thought-out ideas!

With all the talk of tags and folksonomies, I've started wondering whether it might be possible to pull a similar trick with structured metadata - i.e. reducing the precision and accuracy of the metadata in return for increasing the simplicity of metadata creation.

I suspect this idea would cause more problems than it would solve, but exploring it is interesting. For example, you could use the same s,p,o triples model as RDF, but with words(tags) instead of URIs.

E.g.

phildawes isa person phildawes age 29 phildawes worksfor drkw phildawes fullname "Phil Dawes" phildawes plays frenchhorn frenchhorn isa musicalinstrument etc..

Of course we'd have to capture and rely a lot more on context information for ultimately differentiating between two different 'phildawes''s etc.., but the payoff for this increased ambiguity would be simpler creation of metadata and potentually a lot more of it.

At work our most important rdf usecase is having an aggregated store of linked data that can be text-searched and navigated. Since the results are always parsed by humans, this tag approach would probably work quite well here.

<20 minutes later>

Ok, I've refined the idea a bit. Instead of a single tag for each resource, we could use a collection of tags to disambiguate it a bit. The collection of tags could be in brackets or something:

(d156126 dell desktop pc) price (749.99 uk pounds) d156126 isa (desktoppc pc personalcomputer) d156126 ram (512 megabytes) d156126 harddrive (40 gigabytes)

(The convention in the above is that the first tag in the brackets is the one you will use to identify the resource in other statements.)

I suppose you could use a pattern-matching query language similar to sparql to search through the metadata, albeit with a lot less precision. Maybe

select ?a where ?a isa desktoppc ?a price ?b ?a ram ?c AND ?c < 900 AND pound in ?c

(assuming some stemming for pound)

Hmmmm... Reducing the accuracy of the results would probably allow for a lot looser query syntax. I suppose if you take this to its natural conclusion you get a text search, but this is obviously a little more structured than that.

It's difficult for me to tell if this is worth persuing further or not. Will sleep on it and think more tomorrow.