The tag triples idea is going quite well. Have built a simple prototype to test the idea, and have tried populating it with data from work. It's interesting working with a sort of triples-soup rather than well structured RDF. Things link when you don't expect them to (because the tags match) - this is especially handy with literals. (e.g. 'Phil Dawes' literal matches other mentions of my name because everything is a tag in tag-triples)

The big problem is when you have different things with the same tags in localised context and you want to be precise about which one you mean. AFAICS this doesnt happen often when you author the tags yourself (because you choose to make them unambiguous), but it happened today when I exported tag-triples from an SQL database. One such triple was:

BondTrader prodEnvironment BondTrader

(the subject being BondTrader the application, the object being BondTrader the production unix environment).

This is obviously a bit of a problem. Exporting from a database is also a common usecase at work, and so I'd like to get this sorted.

Possible Solutions:

1) Leave the system as it is, and force people to disambiguate their tags in the context of a single graph. e.g. BondTraderApplication prodEnvironment BondTraderProdEnvironment

2) Add some sort of namespacing thing

Application:BondTrader prodEnvironment Environment:BondTrader

3) Make more use of context tags

BondTrader prodEnvironment BondTrader (environment)

(where the 2nd BondTrader is described in a document with a tag 'environment')

4) Do something logic based with the property

prodEnvironment range Environment prodEnvironment domain Application Environment distinctFrom Application

5) Seperate the notion of resources from tags, and define a resource as being identified by n tags.

(application BondTrader) prodEnvironment (environment BondTrader)

Analysis:

1: doesnt solve the problem, although it keeps the model and implementation simple. Would need to change data in database, or have some export mapping.

2: Namespacing is interesting, although it increases complexity. Take namespaces to their natural conlusion and you pretty much end up with RDF. Also you don't get serendipity in the data, as people have to know the namespace to match the tag. Could enable and disable namespace disambiguation in the tool to get serendipity back. hmmm...

3: This is also interesting. It would mean removing the ability to use ids to match tags internally, since you'd have multiple 'senses' of a tag.

4: This is just too complicated. It might be possible to reduce the complexity a bit, but I can't see people understanding this immediately (which is sort of the point)

5: This is really interesting, if not a bit computationally expensive. Also some tags are more important to the resource than others - e.g. BondTrader is more important than Environment. (e.g. What happens when you want to discribe the type "Environment" - you'd have to use '(environment type)' or something). Can't help thinking this is just an extension of describing the thing.