Universal tagging

[killua-eu]

Glued is designed as a lightweight framework for rapid development of microservices that can be easily stacked into large-scale application. To achieve this stacking, a minimal "common glue" can be shared across apps. This common glue is the RBAC Auth and Universal tagging.

Universal tagging acts as a layer binding together data across modules/microservices. Consider a situation, where we have

t_tag_assignments

• c_table (table name - i.e. stor_links)
• c_uid (value of c_uid in t_name - for joins)
• c_tagname (tag name, i.e. #mytag, #dunce, or #year)
• c_tagvalue (tag value - some tags, such as the #year tag can have a value, i.e. 2014)
• c_system - system flag tells if the tag has a special meaning to the application. i.e. in
  • ohno/145 the tags {profile,profile-current,doc} will have the meaning of subdirectories (of ohno/145)

tag_anthology - a list of all tags.

• tag_name
• tag_synonym
• tag_synonym_lang (default value accorging language settings)
• tag_flags (1 = default/preferred name for language defined in tag_lang)

tag_uid          tag_name           tag_lang                       tag_flags
1                účetnictví            cs                              1
1                účto                  cs                              0
1                bookkeeping           en                              0
1                accounting            en                              1
2                noha                  cs                              1
2                leg                   en                              1

[pohadkar]

nebudou tam ty UNIX ACL sloupecky?

[killua-eu]

UNIX ACL columns will not be included in the tag_assignment, but rather inherited from { t_name ; c_uid } of the object being tagged. In the tag_synonyms table, I'm not sure yet. Generally it doesn't make sense to have one tag synonym editable by one person and a different tag by another, so I guess we'll only have table-level rights applied here and omit the row level authorization.

[pohadkar]

tag_synonyms se pry ma jmenovat tag_taxonomy

[pohadkar]

rychle dotazy:

• nemela by se tabulka jmenovat t_tag_assignments ?
• sloupec tag_assignments.c_system ma mi hodnotu jen 0/1 tedy ma/nema specialni vyznam, nebo v nem budou i nejake specifikace, jaky specialni vyznam ma?

[killua-eu]

t_tag_assignments.c_system decides if its a user defined tag (value = 0) or a system/application tag (value = 1). System tags may be (app from app) displayed the same way as user tags, or differently. For example, a contacts / address book app might allow to

• set contact's profile picture
• have a gallery of photos related to a contact
• have a folder of attachments relevant to a contact.

Differentiating between these files would be done by a system tag (meaning that the system tag is actually hard-coded in the source of the app, whereas the user tags is just a freeform text a user can enter - the calendar application will not give the tag any special meaning). Uploading then a company logo as a profile picture of the company would require to tag the image with a tag [c_tagname=profile_picture, c_system=1]. If a user decided to tag the image with the "logo" tag, it would be written as [c_tagname=logo, c_system=0]. If a user would try to "break" the system by setting a user flag [c_tagname=profile_picture, c_system=0] that has the same tagname as the corresponding system flag, user shall be screwed as the application will only consider system flags in its logic.

[pohadkar]

pockat, tak tady mi neco nehraje. jestli to ted chapu dobre, tady to tagovani nahradi spoustu sloupecku a mozna i tabulek, ktere by jinak byly u te aplikace/modulu? tak to mi chvili potrva nez to v hlave zpracuju. takze k profilu nahraju obrazek. to se ulozi jen do storu??? a oznacim ho (tedy system ho oznaci) jako profilovy obrazek. to se ulozi do tagu. do samotne tabulky toho modulu s profilama se neulozi nic??? vse se osefuje storem a tagama? prijde mi to jako celkem velka zmena. a budem se vzdy dohadovat co teda vlastne bude ulozeno v ramci modulu a co uz ne. a nebo to zas chapu spatne a ten obrazek bude mit i nejake id v ramci sveho modulu?

[pohadkar]

pripad kdy by to delalo problemy. napriklad serazena galerie obrazku. at se na to divam z kterekoliv strany, tak jen storem a tagama to neseradis. teda abych byl korektni, muzes tomu dat tag order s ruznyma valuema, ale to by se za prve uplne brutalne masochisticky menilo a porusuje to klic tabulka + uid + nazev tagu. takze nepredpokladam ze chces poradi obrazku v galeri delat tagama. to ale znamena ze musime mit galerii ve vlastni tabulce a to znamena ze se nam zase samy tvori vyjimky :)) kterym ses chtel vyhnout.

[killua-eu]

je to universal tagging protoze ma propojit tagovani napric moduly do jedineho logickeho celku. tagy na urovni aplikaci se budou chovat jako tagy. tagy na urovni filesystemu se budou tvarit jako adresare (vic tagu = zanoreni do podadresaru). priklad s profile photo - muzeme ho ukladat do

a] stor_path="ohno/123/profile" stor_filename="picture.jpg" tag="" b] stor_path="ohno/123" stor_filename="picture.jpg" tag="profile"

oboje jsou možné, rozdíl je v podstatě v tom, kde začneme pracovat na úrovni tagů. toto bude asi modul od modulu odlišné, resp. nedokáži teď spíš dát nějakou jednu odpověď. Dá se asi říct, že path je hardkódovaný endpoint odkud se začínají používat tagy.

Ad galerie - nerozumím řazení. Pokud tím myslíš uživatelem definované řazení obrázků, jak se mají za sebou zobrazit v galerii, tak se to tagem ta udelat pomoci tag_name=order, tag_value=1 ... obecně bych asi pro takovéto účely nepoužil tagging ale rozšířil bych store_links tabulku (dokážu si představit tam mít navíc c_create_ts, c_create_userorder a další ... asi bych toto ale řešil až ad hoc).

[pohadkar]

vse bude jasne, kdyz mi reknes jedinou vec. bude mit obrazek v galerii svuj unikatni uid? z toho co pises jsou mozne oba vyklady. 1 obrazek = 1 uid? ano / ne? a nez odpovis, uvedom si, ze ktere tabulky to uid bude. ono to totiz vypada ze to uid bude z te tabulky t_stor_links. jenom z tehle tabulky. v ramci modulu profil obrazek v zadne tabulce nebude. je to tak? takze ten tag se bude vztahovat na zaznam v tabulce stor_links

[killua-eu]

Po dlouhé úvaze navrhuji řešení tagů obrátit vzhůru nohama.

1. je fajn mít synonyma a překlady tagů. ontologii bych proto zachoval.
2. t_tag_assignments.c_system je trochu úlet. smyslem bylo narvat do jedné tabulky tagy a flagy. s odstupem myslím, že to není dobrý nápad. flag má význam logický pro aplikaci (např. to, že je něco profilová fotka je vlastnost, tedy flag), tag má význam popisný.
3. mít jen c_tagname je ok. mít c_tagname a c_tagvalue je divočina, protože do tagové struktury vnáším metadata.
4. mit toto vše jen v jediné provazovací tabulce je také moc. měli bychom mít i duplikát těchto dat u toho, čeho se to týká.

Návrh:

• zachovat ontologii, což znamená podporovat krom freeform tagů také předuložené tagy. každý tag by pak byl popsán dvojicí [id, hodnota] pro předuložené [null, hodnota] pro freeform. Uživatel by viděl samozřejmě jen hodnotu.
• definovat json podschéma pro tagy, toto podschéma dodržovat napříč celým gluedem.
• uvědomit si, že flagy jsou už v podstatě implementovány v https://github.com/Vaizard/glued/wiki/RBAC-Authorization (statuses). naprosto dava smysl nstvit status profilove fotky, protoze profilova fotka treba bude vzdy viditelna.
• pro urychlení lookupů typu hledám vše s tagem účetnictví (kontakty, wiki stránky, soubory, issues, eventy) použijeme sekundární tabulku v duchu původního návrhu.
• metadata typu key-value pair např. [rok, 2014] jsou application/object specific. u issue nema smysl mit metadato skladatel, u mp3 souboru uz ano. můžeme se časem podívat, zda vůbec lze vymslet nějakou sdílenou strukturu, ale spíš to vidím tak, že žádná nebude. key value par je také třeba typ telefonního čísla a tel. číslo [práce, +420602102030], a to uz zabihame do okamziku, kdy metadata splyvaji s daty a to je cesta do pekel. a i kdyby slo o metadata vztažená na soubor, pak patří víc k popisu objektu samotného souboru, ne jeho linku.
• mohlo by dost být užitečné podporovat uživatelské tagy a metadata (ty, ktere uvidi jen vlastnik).jsou přecijen metadata, ktera chces sdilet se vsemy a pak metadata ktera se sdilet nevyplaci (napr. oznacovat cloveka tagem kokot).

Poznámky mimo rámec tohoto issues:

• krom tag lookupu by mohlo by mít smysl mít také lookup tabulku na interakce mezi lidmi nad objekty. napr. kouknout co spolu maji spolecneho petr a pavel. vyplivne to spolecne ukoly, udalosti, atp.