No more tags!

Seriously. Wrong path. Blind alley. Tags are out. Full stop.

Yeah, yeah, I know I've been a strong proponent of tags - but now I accept I was all wrong, very wrong.

Tag me with "France" - would that entail my passport is French? That I live in France? That I like the French Alps? (Two last applies)

Tagging subjects is like ripping the verb out of a sentence.

"Sig France", eh?

Put the verb back!

Try for example "Sig + lives in + France" which technically is "subject + predicator + object" which, for those of you who are conversant in the "Semantic Web" is similar to W3C's RDF N-Triples (heh, how's that for a mouthful).

In other words, a methodology and even a technology exists already that "puts the verb back". So why not use that?

This framework has been around since 1999, with a new version since 2004 - but still it has not caught on despite it's intriguing prospects.

I would dare to suggest that this non-use is due to how information is stored:

The free-forming cloud, the "web", as well as enterprises still handle information in mashed up formats - "documents" and "forms". Storytelling. Mashups.

A "document" almost always consist of many objects - address, author, many subjects and even more objects - like a vat of 12 liquids nicely mixed up.

Add a triple saying "vat contains inflammable liquid" - which one of the 12 liquids does that apply to? If the information had been stored as 13 singular objects, 12 liquids + the mix, then triples could add real useful knowledge.

Luckily thingamy uses only singular and minimal objects to build models of reality. Thus triples can be used with aplomb.

Out goes tags, owner, place and links - our current "object knowledge enhancers" - to be replaced by one single method; Relations (triples) - and with that; one single term to get head around, no limits to knowledge enhancement, real precision and less code.

So apologies (again) to those of you keen to put your hands on something (almost) finished, just have to get it right when I see a flaw.
Bugger, it's not easy to be "on time" when you're breaking all the "rules", then breaking your own rules.

More on how we're doing it and how it's going to make thingamy simpler and more powerful than ever in post to come.

Comments

[Bruce Stewart]

I used to argue, some 20 years ago, that relations were far more important than objects. I never pushed it as far as to say that "it's relations that are real and objects that are imagined" but in reading this this morning it is now clear to me that that was where I was headed.

When it comes to the morass out there, what matters is the context that relational statements provide. This is (if you recall the Newton) what makes the data soup function in a useful way.

Good article, thanks for writing it.

[Hamish]

Ike! Well, mad props for working the problem, and having the courage and discipline to continue through to the right answer.

Actually, its rigorous thinking that solves the problem, and that's something that seems to be falling out of fashion in some circles.

I would love to see the new approach in action, it hits a note with me, at least.

[sig]

Bruce,

when you say "relations were far more important than objects" you're spot on the Semantic Web / RDF thinking. The beauty about triples is that you can in fact replace all properties of such with triples - and I would love to do that, been tinkering with it... still do. But we have the issue of using some objects as "containers" keeping a tab on number of pills or liters of liquid therein. Important stuff to keep an eye on for enterprise systems one might say :)

In addition we use "object driven" instead of "event/transaction driven" workflows.

Thus we drifted towards a hybrid - proper objects with properties, then using triples as "knowledge enhancers". But more on that later!

[sig]

Hamish,

good to get a stroke for being stubborn!
I find solace in what Kathy Sierra's horse trainer says: "Take the time it takes so it takes less time!"

So glad my "investors" allows me to do the right thing... shoot, there goes the wine budget again :D

[Ian Prince]

Hi Sig,

Interesting atticle, as always. Might "going RDF" be throwing out the baby with the bath water....?

IMHO full-blow RDF is hard in the real-world. Tags on the other hand are beautifully simple and easy.

Maybe a half-way house is in order? Have you considered attribute-value data modelling where tags are "qualified"? In your example that would give the object Sig the attribute "lives-in" with value "France".

[sig]

Ian, lemme me:

1. "Full-blow RDF is hard in real world" - as you can see from the post - I think it's even worse, rather impossible as information is still contained in mashups of objects (documents, web pages, forms) and that simply does not work with predicators, thus RDF could not work. But that's why thingamy have a chance as we work with minimum singular objects only.

2. "Half-way" is rather precisely what we do - keeping the proper objects thus only needing to add the predicators. Had the issue of some objects being containers of screws, pills and such enabled for transactions...

3. "Qualified tags" - but of course, that is precisely what the triples attain: The subject being the variable you're working with or object you're looking for, the predicator being the "qualifier" and the object being any object in the system. The little trick we're using there (more about that in later post) is to allow the "builder" to add what we call "functional classes" like location, work function etc. so you can define 'France', 'Warehouse B', 'MD', 'Nurse' and whatnot. Thus the old "tag" of 'France' becomes 'lives in + France' and 'speaks + French' and so forth. Think "tags" -> functional object then add the 'predicator' as qualifier and voila!

4. "Throwing baby out.." - the good thing is that we really only is cleaning up, replacing the four knowledge enhancers (place, owner, tag, link) with one single system that allows to replace those four and any other you might dream up - and that with a yet unknown precision! That should simplify use methinks, easier to grasp one term than four, and the terms are semantic to boot. Did I mention simpler code too? What's not to love then? :D

[Balaji Sowmyanarayanan]

Plain old Tags to be replaced with lispy First Class objects in Thingamy? Awesome!
Stealthy cherry in the cake? Good Show!
Cannot wait for the next post!

[Tomi Itkonen]

"... to add what we call "functional classes" like location, work function etc. so you can define 'France', 'Warehouse B', 'MD', 'Nurse' and whatnot."

Sig, are these functional classes similar to the classes in OOP languages like Java?

In Java, you could first define a Location class. Then you would create an instance of that class, like this:
Location france = new Location("France");

[sig]

Tomi,

without being much of a Java expert (so not!) your description fits.

In fact, in the system when you build a model of an enterprise or organisation a part is to define classes which you then use to create instances or objects with. (After all, the whole idea of enterprises or organisations is to take tangible or virtual objects and add value to these in sequences using other objects).

When you create classes in our system you have to choose a base-type that is useful for the system later:

Say "nonaccounted-user" type that is used for classes for persons or organisations that will use the system - it has certain default properties given like username, password, e-mail and such.

Ditto for "accountable-item" and "accountable-container" that has default properties pertaining to value and for container, initial and current amount.

The "functional" type will not have any default properties, any properties must be defined by the user when she "builds" the class - but it has the ability to be automatically added to a separate builder interface where the builder can add instances for each "functional"-type class as these might not be typical objects that you will add value to nor use in workflows. They're there for one purpose, to add knowledge to other objects.

[Thomas Otter]

Sig,
Indeed there is something to all of this RDF, OWL and co. I'm still figuring it out.
more here.
http://theotherthomasotter.wordpress.com/2007/09/28/semantic-webness-record-collections-and-tags/

[Luca Manassero]

Sig, I know how hard can be to spot a design "issue" and have the "guts" (and the money...) to fix it. And I am glad for all of us "Thingamy users" that you decided to do it.
In fact I went through a number of situations where the tags metaphore did not seem like the right way to do it.
One example for all: a typical bill of materials relationship with top level items and components (and/or machines). Fairly boring manufacturing stuff, uh?
If you end up with 2-3,000 end items and 200-300,000 components you can forget about using tags.
Triples, will see. They look promising.

Breaking your own rules? Well, maybe. Knowledge has been defined a long time ago as the process of adapting your understanding to things. It's always very, VERY hard ;-)

[Ram Manohar Tiwari]

Sig + lives in + France

And do you mean "Forever"?, "Happily"? :)

Is it just about putting the "verb" back?

Cheers,
Ram

[sig]

Luca,

and your and other's patience is very much appreciated while I tinker!

The neatest of the really old definitions of "knowledge" is my favourite - Plato's - "knowledge is how objects relate to other objects". If you saw a cup for the first time ever, it's when you get the idea that you can pour liquid into it and lift it to your lips - i.e. the relationship between objects - that makes it useful.

And thus "triples' being pure relationship definers between objects should be pretty pure knowledge enhancers!

Just the little detail to get it into a format UI wise etc that makes it easy to use... but that's just another job... ;)

[sig]

Ram,

excellent example which I'll grab with gusto:

The "predicator" of the N-triple is per definition "a verb phrase considered as a constituent of clause structure, along with subject, object and adjunct".

In thingamy the one who builds the model will define predicators at will - for whatever need your reality requires.

So you could add predicators beside the "lives in" like "lives happily in", "lives against his will in". Or one could use two or more, combine "lives in" with "does not like" or "likes" :)

And then you add a triple "sig + has spouse + Tittin" while Tittin has a triple "Tittin + thrives in + France" allowing a report of persons who either likes the place they live in or have a spouse who like the place they live in. And so forth ad nauseam!

No system-practical limits to knowledge with other words!

[Ram Manohar Tiwari]

Hi Sig,

Thanks for the explanation. But for the sake of curiosity:
How would you handle the time/object dependency?
I am not sure if I am able to convey my question properly but..

I need a report of People whose spouse likes to live in France as of a particular date. Because there are some people who likes to live in France during summer and summer of France is from Date1 till Date2 ( and the dates depend on the year )...

[sig]

Ram,

ah, there we are in front of the issue already: Every object in the system, not only the objects used in processes, but also system objects (from the build of your enterprise model) are time stamped and keeps a tab on all changes to all properties and who did it.

In other words reports can use time-period or point of time in combination with whatever other data the object holds.

"Just for fun" we have a "historical browser" - go back in time and not only do you get the system including report templates and workflow settings as they were on that date and minute, you get the objects and all the property values as they were then (i.e. if you have added properties later those would not show) - even layout changes to exactly what it looked like then.

Delete something, even an object and it magically reappears in historical browsing (nothing is ever deleted, just hidden). Add a log and all is set to cover SOX, Basel II and anything else you can throw at it (as long as the processes actually are used).

An important part is that thingamy is "object driven" - i.e. the objects follows the defined processes and initiates the events, and even or transaction is purely a change to an object done by an assignee. And that data - time, who, what - is captured and can be used forever.

BTW, you being a SAPpie - are you going to the Teched in Munich in October? If you do let's meet up and I'll show you!

[Ram Manohar Tiwari]

["Just for fun" we have a "historical browser" - go back in time and not only do you get the system including report templates and workflow settings as they were on that date and minute]

Viewing the history is easy but viewing the history from the eyes of historical characters ...only if your workflow engine and complete architecture [ and hardware :) ] can go back to the historical date, you should have called it the Time Machine.

Incidentally, yesterday I was thinking about an archiving requirement to keep the record of invoice outputs sent to the customers. And I thought only if all my settings and programs/underlying engine can revert back to the old date, I may not need any archiving solution :) And not only I can find the original invoice sent but also that why it was incorrect [ as I can run the historical system/programs/sapscripts/data ] .

And then I realized that I am asking for a time machine.

But I generally like the "Just for Fun" stuff from inventors because in essence those are the real additions. Something so new that you cannot justify it otherwise but by calling it "Just for Fun".

Many thanks for your answers and the invitation. Unfortunately, I will not be there in TechEd. Just to keep my innocence intact ;-) .
But I will keep an eye here.

[pihl jones]

Nooooo!

Sig, don't do it. This is *suicide*! The point about tags is, that however ambiguous they are, they are *easy* for your users to figure out.

Triples, relational models are not. As Ram points out, just because you model using a relation rather than a bunch of tags, doesn't mean you eliminate ambiguity.

Forcing a more complex representation syntax on the user won't save them from ambiguity.

Let the users work out their own modelling schema. One which works for them.

If they want to use tags called "verb-resident-in" and "object-Sig" and "subject-france", let them. If they don't, don't force it on them. It won't help, and in the worse case, will get you into the no-win situation of trying to "help" them by defining a business modelling-schema of your own.

And then two further bad things will happen :

a) your schema won't fit their business and they'll reject Thingamy

b) they won't understand your schema, it will look too complicated for them, and they'll reject Thingamy

As I see it, the selling point of Thingamy is that it's a completely non-comital about schema and let's the users or VARs model their business as they like. Getting involved in the SemWeb will take you away from there.

[sig]

Phil, excellent, excellent!

A real good nudge I must say, much appreciated such brain-activity-inducing pokes, so let me try to address the issues:

First of all I agree heartily that simplicity and freedom comes first.
The thing about any property that is added to an object is that it requires precision as well as simplicity:
1. so a user can understand what the adder of knowledge meant, and
2. so an IT system can make use of it when it's supposed to "pick up" an object following some rules in a run or when applying accounting rules to the objects.

Coming back to the current system; I found that we needed (semantic tags) place and owner in particular for accounting purposes, links were mostly useful for report production while tags were the most iffy ones while very generic.
Place and owner are very precise and thus also very easy to use - but at the end they are triples - widget is located in warehouse B.
Tags I still believe can only have any practical use if multiple-tags-filtering is available and we have that.
But still, user-friendliness is so-so. Just due to the simplicity in fact - every post herein I tag for Technorati, and every time it creates some head-scratching and a less than perfect result.

In fact because of the limitations described just by using four different "knowledge enhancers" (place, owner, tag, link) I do impose a schema upon the user, which is limiting, slightly hard to understand and thus bad.

Enter triples, and please disregard the Semantic Web here (as mentioned I do not think that will work as long as the objects in the cloud are mashups of objects) - I'm only using the semantic idea:

Subject + Predicator + Object.
(Relating the Subject in a specific way to the Object and vice versa).

The subject is given - that is the object you're looking for or the object you're adding information to.
The objects are a natural part of the system anyway - just define them as today.

So the only new thing is the predicator. And I would argue that the information delivered by the predicator could be quite precise, as precise as semantics allows (even programming languages are semantic so it should be possible to have a high degree of precision).

This will for the user be schema-free as she can define these freely at will (albeit same issue as for tags: Shall end user or only model builder be allowed to add? I'll leave that to system owner).

In that case she can, if she's a true believer in tags, add a triple to the system like this: [subject] has tag [tag] where [tag] is a class of tag objects just like today. Thus adding this triple to an object would be identical to the tagging today.

Then when hit by the iffyness of that sentence (as today) she can add another triple to the system - [subject] has owner [owner] and so forth without limits according to her organisation's specific needs.

In other words, I'm moving from a schema restricted to four "knowledge enhancers" to a freely definable schema for "knowledge enhancers" - or rather "relationships" as Plato defines knowledge.

As to ease-of-use. Well, an answer will be in later (after some tweaking I suspect!), but: Predicators like "lives in", "likes", "is owner of" - are easy to understand while giving a high degree of precision.
I for one struggles more with tags as I choose one and start thinking "but what do I mean by that?". When I add "lives in France" to myself as subject it comes quite naturally!

And I do count on one thing - it should be easier to understand one method - add a predicator and object to a subject - than to get my head around when and how to use place, owner, tag and links. I am sure you as a programmer will see how it simplifies code as well - that I like a lot too! :D

I see that I need to do two more posts soon - been mulling over them for awhile - one more detailed about how it will "look like" in thingamy in practice and one on my belief that the Semantic Web will not work (for now) and that the only place to use the otherwise intriguing concept is in a controlled environment where you can minimise the information to singular objects!

Apologies for such a long and iffy ramble! Would love to do a Skype and discuss the finer details if you have the time - interesting issues these!

[Stephan H. Wissel]

Hhm...
Triplets...

I would say a "simple" Tag carries already more information.

"Paul" [tagged] "Carlsberg" with "Drinkable" on "24/3/2007". So the Tag contains:
Who did, what action, to whom, with which result and when. Where "which result" would be the tag value. The flaw of the tag is that the action is that the verb is static "has tagged". So the real thing are the triplets but with Meta data: Owner, lifecycle and related relations (ouch).
Sig lives in France since 1998 (according to Paul), before that look here... Sometimes the source of a relation is not relevant, sometimes it is, especially if there are conflicting relationship information.
:-) stw

[sig]

Stephan, you're cheating ;)

No, not really, very good point you have there, although:

By cheating I mean drinkable is an adjective with a clear hint as to what type of object. "Carlsberg, drinkable" is a "boiled down sentence.
Using triple it would be something like "Paul, terms as drinkable, Carlsberg". Not pretty though, but I'm sure your English is better than mine so you'll find a better one!

Actually, being strictly philosophical, I'm leaning heavily on Plato's definition of knowledge - how objects relate to other objects - and that's what the triple delivers. It's simple, it's powerful, it's human _and_ machine readable.

And, it's not more work, instead of defining tags you define predicators - the objects are there already. You could even call the predicators tags :)

Ah, must add, when defining a predicator one must create the inverse too, as adding a triple means that you can use it both ways - inverse or not. "Paul, likes, Leffe" - "Leffe, is liked by, Paul".
And with that - as a triple is a standard - a machine can understand it as well and would yield a result for obscure queries like "List relatives of Paul that likes Heineken and that cycles on a Colnago while not being fit" :D

[Mike Howard]

Tuples are too Rigid - just as tags are too simplistic.

The problem is not Tags versus Tuples. A set of tags for a document is the 'right' thing to have. Confining the search to individual tag values is the problem.

Search is inherently un-informed in that we don't know what we are lookiing for and have inadequate descriptions of what it is we are looking for.

If the search is works with sets of tags - dynamically generated - with additional tags dynamically suggested, then you will get the effect of dynamically created tuples which are taylored for each instance of search.

To expand:

You start a search by typing a list of 'key words' or tag values.

Click the 'refine' or 'suggest' button. You then get a tag cloud with your values + tags which also occur with your values. Everything is color coded with 'selected' / 'not selected'.

You click some more and repeat to get more refinement of the tag tuple.

when satisfied, click the 'show' button which then displays descriptions of matching items.

Will it work? I don't know. Basic Information Theory says that the information content is inversely related to the probability of occurrence, so suggesting frequently occuring tag clusters has less information than infrequent pairings.

Frequent pairings might be good to go from 'general description' to 'current buzzword' or in reverse.

Just a thought

[sig]

Mike, agree that use of multiple tags (we used that) makes human "browsing" easy, tinkering about while the exact "thought" is still elusive... and the more tags an object is tagged with the more precise the multiple filtering can be.

The thing is that the N-triple, being a standard, is directly machine readable thus allowing queries beyond the next object, and obviously it is really human readable too.

The "rigidity" delivered by the predicator describing the relationship between two singular objects is kind of required if you want precision.

That said, you can at all times create a predicator - "is tagged by" while having objects that are tags - then you for all practical purposes do have tags.

Reason why I want precision, is that it delivers knowledge directly - and precise as such which in an enterprise system (like thingamy) in many cases is required. Accounting comes to mind!

[Andy Dale]

This reminded me of some work I did a while back that explored not just adding the verb back in but also added identity into tagging. Who says "Andy Lives in France"? and why should I trust them (I don't). Once we add in identity we can add reputation and graph the subjectivity of assertions.

Check out i-tags at http://www.itags.net/index.php/Main_Page. I think that there is still improvement that can be made with it but I think it's a good base. A couple of key aspects being that both the tagging advocates and the microformat community seemed willing to embrace it and it is fully backwards compatible with rel tags so existing tagging infrastructure doesn't have to have a discontinuity but can evolve.

Andy Dale

[sig]

Andy, interesting the itag idea!

Putting on my free-thinking hat, I would argue that you are using a twist to RDF N-triples, or part of it - as would I in our effort in the enterprise area (where one has better control over the object format).

Actually, using more than one triple may add that identity, author, license and even more to the soup so you could attain the same with triples methinks, albeit not elegantly all-in-one of course. But with the smaller triples, and use of more, more than identity and the above can be added to objects, all kinds of relationships and even spanning beyond the next object...

Ah, interesting area this - almost more philosophical than technical :)