comment on the SemanticTags proposal

This commit is contained in:
Fischlurch 2012-10-10 06:11:32 +02:00
parent 64e6d37bb8
commit 2867dc1870

View file

@ -139,6 +139,59 @@ Comments
--------
//comments: append below
//edit comment
You may recall this proposal created some heated debate at the last developer meeting.
After thinking it over some time, I can see now more clearly what irritated me.
. for me, the proposal seems somewhat to lack focus. Right now we have some shortcomings at
rather basic operations when *authoring content* at the website. This proposal tends to be more
interested in some kind of automated content discovery.
. the term ``tag'' in this proposal is overlayed with different meanings. For one it means an attached
textual property of some document, but also it denotes to some kind of inferred categorisation.
I'd rather propose to stick to the former meaning (which is common place) and treat the latter
as one _source for data_ within an categorisation algorithm. This way, such categorisation
sources can remain an implementation detail and don't need to be fixed in an universal way.
. I have serious concerns against the _ontology_ part of the proposal. Not only is the syntax
unintuitive, but more importantly, this ontology is not well aligned with real world usage.
+
To underpin the last diagnosis, just look at the existing tags in our Wiki:
* automation (3)
* Builder (20)
* classes (6)
* Concepts (9)
* decision (19)
* def (90)
* design (43)
* discuss (19)
* draft (55)
* example (3)
* excludeMissing (6)
* GuiIntegration (6)
* img (40)
* impl (36)
* Model (22)
* operational (19)
* overview (20)
* Player (12)
* plugin (2)
* Rendering (24)
* rewrite (3)
* Rules (8)
* SessionLogic (30)
* spec (76)
* systemConfig (9)
* Types (4)
The absolute majority of these are neither _is-a_ nor _has-a_. The great thing with
tags, why everyone seems to love them, is exactly that they are *not formalized*.
You can just throw in some tags and keywords and use them for a plethora of
unrelated and unstructured purposes and generally just assume that your
reader will somehow ``get it''.
Ichthyostega:: 'Mi 10 Okt 2012 05:36:35 CEST' ~<prg@ichthyostega.de>~
//endof_comments: