Vlákno názorů k článku
eWorkshop: Návrh sociální sítě budoucnosti

Takže nový thread, kterým chci navázat na naši diskusi s Igra, ale i znovu nalákat další kolegy k diskusi...

Zatím jsem tady tady shrnul rozdíly v našich pohledech na architekturu systému - budu z toho prozatím vycházet.

Ten Igraův způsob se mi začal líbit víc kvůli tomu, že nejdřív zužuje pole vyhledávání a pak až používá hrubou sílu vyhledávače... ale přemýšlel jsem nad oběma, a hledal další potenciální problémy (nejsem posedlý problémy, ale myslím, že když chceme udělat díru do světa, musíme vymyslet velmi odolnou architekturu;-). Našel jsem zřejmě další problém v tom profil-centrickém způsobu - když budu mít firmu v nějakém oboru nebo se v tom oboru budu chtít prosadit, prostě si na internetu najdu osobu, která je velmi populární a respektovaná v tom oboru, a pak prostě vezmu jeho profil a okopíruju jej do svého. Vyhledávací dotazy typu link:diskuse mě pak vyhodí do výsledků, i když jsem se těch diskusí vůbec nezůčastnil.

Prostě ta UPI-centrická metoda, kdy prohledám fultextem web na výskyt UPI-tagů a pak je pomocí lokálního klienta porovnám s profilem (pokud možno s jeho lokální kopií) a výsledky vztahující se k tagům neobsaženým v profilu vyřadím, je méně elegantní, avšak asi robustnější. Mohl bych ovšem zvolit hybridní metodu, kdy použiju link:kde_prohledat a následně výsledky lokálně profiltruju podle profilu.

Nevýhodou vyhledávání pomocí link:misto je to, že vyhledávače zatím údajně neumí prohledávat web na výskyt linků na mnoho míst současně. Možná by se to dalo řešit nějakým skriptem řetězícím dotazy v rámci klienta... případně používat čistě UPI-centrickou metodu a na hybridní přejít v případě, že to začnou vyhledávače podporovat.

Také tady padla otázka na vhodný formát těch profilů - asi bych za základ považovatl prostý text, nebo dejme tomu html/xml, aby se to dalo zpracovávat - dokážu si představit spoustu možných způsobů, jak z toho profilu pomocí jednoduchých nástrojů vyfiltrovávat různé podmnožiny podle nejrůznějších kritérií, dalo by se s tím dělat spoustu dalších "zaostřovacích" funkcí... a nějaká ta barevná layer nad tím, pro případ že by si ty profily nědo prohlížel na vlastní oči, se nad tím dá dodělat vždycky.

Čím dál nad tím přemýšlím, tím víc možností co by se s tím dalo dělat mě napadá. Pokud navíc udržíme architekturu co nejvíc modulární, aby k co nejvíce částem se daly vymýšlet alternativy, různé způsoby jak využívat ty zbývající části... Navíc můžeme doufat, že v případě, že by se něco podobného rozšířilo, může tomu i další podoba internetu vyjít vstříc - jistě by to možnilo spoustu služeb, které dnes nejsou možné a třeba ani potřebné...

Stručně řečeno - to, co nám z tohoto workshopu vyplynulo, mě zajímá a rád bych to ještě rozvíjel, a třeba začal malinko testovat v reálu - jen tak improvizovaně, ručně uploadovat data na nějaký free webhosting, ručně misťovat tagy... prostě ověřit fungování principů. Kdyby se na tom někdo chtěl podílet se mnou, budu velmi rád když se mi ozve na mail (viz nick).

UPItag_honza

Text ne ! Text je pro automaticke zpracovani a rozsiritelnost temer nepouzitelny a i HTML diky propojeni formy a obsahu neni zadny zazrak. Myslim ze nejrozumnejsi reseni je XML a ze navrh struktury toho XML (tak aby to slo pozdeji vhodne rozsirit) bude poradna fuska.

Uznávám, že tomuhle moc nerozumím. Jen mám osobní zkušenost, že v Linuxu - kde je jak známo všechno textově orientované - vidím obrovské možnosti práce s textem - dokážu si představit snadno vytvářitelné, aplikovatelné i šiřitelné skripty pro zpracovávání těch profilů atp. Ale XML samozřejmě OK... koneckonců je to taky text, a nemusí to být zrovna plain, hlavně že to bude nějaký otevřený formát, byť bych preferoval co nejjednodušší. Tohle je určitě na další diskusi pokud to budeme chtít dál rozvíjet... nechám si poradit, načtu si...

Myslím, že dobrý tip je
http://pyxml.sourceforge.net/topics/xbel/

Je pravda, ze linux je plny textovych konfiguraku, ale jejich syntax (vsechny verze) je na slozitejsi zalezitosti nepouzitelna a dost spatne rozsiritelna.

Obavam se, ze asi nechapu, co chcete rici slovy "jejich syntax (vsechny verze) je na slozitejsi zalezitosti nepouzitelna a dost spatne rozsiritelna."
Mohl byste to nejak rozvest? A priklad, kdy je to nepouzitelne, by take zajiste nezaskodil.

Ze je to sice pouzitelne na konfiguraci, ale nema to vyjadrovaci silu potrebnou pro neco slozitejsiho, jako to co chceme tady dosahnout. Hlavne jde o to, ze tam vetsinou nejde udelat libovolne hlubokou strukturu.

I kdyz treba v apache to jde. Vypada to pak uz dost jako XML (dokonce i < je <). Myslim ze jediny element ktery je mozno vnorovat neomezene je if, ale to by slo rozsirit ...

Dalsi co by slo pouzit je konfikurace alsy, ta zas pripomina CSS ...

Priklady nerozsiritelnych syntaxi: crontab, ld.so.conf, lilo.conf, passwd.

Co se tyce testovani ... kdyz si nebudete obsazovat neco tak casteho jako honza, muzete i ted dosahnout zajimavych vysledku. Zatim jsem na internetu (pomoci google) nenasel vyskyt nicku "HKMaly" ktery by nesouvisel se mnou.

V naší diskusi jsme prozatím dospěli ke dvěma různým cestám:

1) vyhledávat primárně ve fulltextu a osobní UPI-stránku uživatele použít pouze pro informaci o jeho čtenářských zvycích či pro kontrolu pravosti zapsaných UPI
2) zkonstruovat plugin tak, aby automaticky vznikala taková UPI-stránka, která je sama o sobě užitečná pro hledání lidí sobě vzájemně blízkých.

Můj názor je, že časem se možná rozšíří přístup číslo jedna, protože nabízí principielně více informací, jako kontext, ve kterém se UPI tag vyskytuje, vzdálenost ostatních UPI tagů, případně ještě i jejich vzájemné vztahy v diskusi; v prvních implementacích však bude jednodušší vyjít z přístupu číslo dvě.
Taková stránka s mojí čtenářskou i publikační historií o mně poskytuje mnoho informací sama o sobě. Informace by byla viditelná veřejně a každý vyhledávač by si ji zpracoval tak, aby ji co nejlépe využil: setřídil podle navštívených web serverů / témat; rozlišil moji novou přítomnost a starou (analogie stárnutí přátelství; když jsem někdy před dvěma lety byl na jedné stránce, a už jsem se tam nikdy nevrátil, nechť je to zapomenuto - hlasuji nohama v tom smyslu, že mě ta stránka nijak nezaujala), stanovil priority aktivní a pasivní přítomnosti atd. Pokud jde o formát této osobní UPI stránky, souhlasím s Honzou, že ve formátu nevidím konkurenční výhodu. Cokoliv jednoduchého, strojově čitelného, z čehož bude vidět, co jsem četl, co jsem napsal, a kdy (stačí den, z důvodu implementace stárnutí informace) je v první fázi OK.

Takže můj názor, kterými otázkami začít:

- Jak přizpůsobit plugin tomu, aby sbíral skutečně relevantní informace (problém návštěvy serveru versus návštěvy určitého tématu - nezapomeňme, hned "vedle" na Lupě se diskutuje o BMI). Pokud tohle vyřešíme dobře, zbavujeme se i přesto, že jsme zvolili "cestu 2" mnohem méně informace, než jsme se obávali. Plugin může chápat zdroje dostatečně granulovaně a zapsat nejen na kterou stránku jsme psali, ale na kterou její část, ba dokonce do kterého vlákna. Hrubá síla vyhledávačů pak může najít stránky uživatelů, kteří obvykle píší do stejných vláken, jako my. Tím se vracíme k syntaxi UPI-stránky. Informace v ní by měla stačit jak k závěru, že Honza často navštěvuje Lupu, tak i k závěru, která témata ho zajímají a, v rámci nich, s kým nejvíc diskutoval - jediné, co díky "přístupu 2" nezjistíme, je o čem :(. (Ale nebojme, i tady by se obezlička našla - můžete ji zkusit navrhnout?)

Vyhledávač pak UPI stránky zpracuje, setřídí podle navštívených míst a nalezne stránky sobě podobné - pomocí shlukové analýzy.
K řešení:
- Jak rychle má informace stárnout? Parametr, který se bude muset vyzkoušet.
- Jak přesně pracovat s tím, že jsme někam aktivně psali, oproti informaci, že jsme danou stránku pouze četli? Určitě je psaní příznakem vyššího zájmu než čtení. Ale kolikrát? Bude se muset vyzkoušet.

Výsledky shlukové analýzy pak bude vyhledávač využívat například tak, že stránky vytvořené nebo často navštěvované mnou blízkými lidmi získají vyšší "UPI-Rank", tedy analogii PageRank, ovšem vztaženého k mé osobě. Vyhledávání by pak bylo apriori personalizované a nepotřebovala by se jakkoliv měnit jeho syntaxe; když hledám slovo "teorie relativity", určitě nechci, aby na prvním místě vyjel Blesk, jen proto, že se v něm o tom pojmu někdo omylem zmínil, a Blesk je holt nejčtenější. Kromě toho bych ale mohl klást i specializované dotazy: lidi, kteří čtou určité stránky a určitá témata (takže bych se snadno mohl dopátrat odborníka na jakékoliv téma), stránky, které byly napsány pouze lidmi mně blízkými, dostávat blogy nebo diskusní příspěvky mně blízkých lidí, a podobně. Oblast aplikací je pak dalším obrovsky zajímavým okruhem k diskusi.

Ad cesta 1:
O tom, jak nebezpečné je automaticky pracovat s informací kolem našeho UPI-tagu (byť je tímto tagem pouhé jméno a příjmení) nás mohou přesvědčit aktumaticky generované profily vyhledávače Zoominfo (které jsem kritizoval už v úvodním článku eWorkshopu). Pravda, UPI je unikátní, takže v něm nehrozí smíchání informace více různých osob do jediného profilu; pracné je ale i rozlišit tak zdánlivě jednoduché věci, jako je pozice a jméno firmy, ke kterým to jméno patří. Takže i proto nabízím začít cestou číslo 2.

Pro testování mě napadla nejtriviálnější implementace prototypu.

Plugin by jenom ukládal/stahoval obsah stávajícího souboru bookmark.
Stačí se domluvit na nějakém prohlížeči s čitelným bookmark soubnorem (IE to asi nebude) a nemusíme pro začátek nijak měnit jeho formát.
Stačí, aby si plugin uměl :
1) při startu vyžádat informaci o UPI stránce
2) vyzvednul soubor bookmark.* z www a nahradil jím lokální (pro větší bezpečnost s přejmenováním původního)
3) vyzvednout si na ní konfigurační soubor (např. uploud.cfg) s informacemi o způsobu a parametrech připojování pro upload informací
4) vyžádal/zprostředkoval navázání spojení pro přenos souborů na www server od uživatele
5) monitoroval změny lokálního bookmark.* a při každá změně uploadoval novou verzi na www server
6) volitelně po odhlášení/při ukončení vrátil na místo původní bookmark.*


Bohužel nejsem programátor, takže ani tento rtiviální prográmek nemohu implementovat sám. Najde se někdo, kdo má schopnost/možnost ho implementovat?