FRAKTALEK: rado se stalo

BARD: super, wikipedia miner jsem neznal. diky!

FRAKTALEK: mrkni na tohle http://www.slideshare.net/josefslerka/smantick-vznam-wikipedie vic uz nemuzu

BARD: jasne, chapu

vidis, na OpenCalais jsem pozapomnel...mozna by to slo nejak chytre pouzit k postaveni vlastniho tezauru

FRAKTALEK: nekde jsme museli zacit, pak uz to jelo samo. byl to prvni set

Na kategorizaci jsme si museli sami napsat, pro anglictinu je prima zaklad OpenCalais

BARD: tweety jsou anotovane geo-lokaci? pokud ano, tak asi ne vsechny, ne?


docela by me zajimalo, jake nastroje mate na kategorizaci. Shanel jsem nejaky tezaurus nebo aspon slovnik zajmu a dovednosti v anglictine, ale nic volne dostupneho jsem nenasel. Nejake komercni moznosti existuji, ale ty jsou momentalne mimo muj dosah.

FRAKTALEK: zacali jsme setem uzivatelu podle toho, ze Twittovali z uzemi CR a SR a indetifikovali, zda si alespon jednou za cas pipnou cesky nebo slovensky. Po tomhle setu jsme uz pak jen crawlovali jejich followery a jejcih followingy a opakovali detekce. V tuhle chvili mame 5 IP adres na WHitelistu Twitteru, takze se to dela vyrazne prijemneji. Na kategorazace mame nastroje, ale nemame zatim cas, protoze se ted soustredime hlavne na Facebook.

BARD: prozradis, jak jste identifikovali cesky a slovensky twitter?

Mate ho rozdeleny treba i podle kategorii, napr. zajmu jednotlivych uzivatelu?

at tak nebo tak, jdu do toho

SATAI: Na druhou stranu, pro nas co kupujeme ebooky, na MBRBG je tam dlouhodoba akce "buy 1, get 1 free".

PAD: pro vymenu a storovani dat pouzivam GraphML. Pokud jde o db, tak v tuhle chvili vyslovene zadnou graphdb nepouzivam, vyuzivam Redis a Ruby. Nicmene se chystam napsat si nad tim jednoduch DSL, ktere budu postupne podle potreby rozsirovat. Zakladni implementace v Pythonu existuje od nekoho jineho a vali se nekde na Gitu.

FRAKTALEK: jde mi predevsim o interoperabilitu - nekdy potrebuju spis batch processing, tzn. natahnout cely graf do pameti a pak s nim pracovat, jindy potrebuju traverzovani ... momentalne pouzivam JUNG, ale neco v nem chybi a hodilo by se spis Gephi (hlavne na vizualizace) a asi by se hodilo se obcas dotazovat i pres sparql ... momentalne mi prijde jako dobry napad jako api pouzivat ty blueprinty s tim, ze jako backend muze byt treba neo4j nebo sail (sesame rdf store), pripadne to lze vylit do toho xml, ktere zase umi cist gephi. kdybych si napsal adapter blueprints-gephi, tak bych pak mohl pouzivat v podstate cokoliv, co je tak nejak pro javu k dispozici ...

moje otazka byla minena tak, ze treba nekdo uz neco podobneho resil a treba vi o lepsim zpusobu ...

PAD: rikal a vysvetlil jsem jak jsem to myslel, viz treba http://www.graph-database.org/implementations/

nejde o terminologii, jde o ten rozdil a ten je potreba zduraznit

co se ukladani tyce, tak prece opet jde o to, co s tim chces delat a jake nastroje mas k dispozici. Vzhledem k tomu, ze tu vetsinou zminujes velky site, tak bych si na xml asi dal pozor... pracovat s XML soubory vetsimi nez par desitek MB muze byt neprijemny.

a vubec - me to privadi k otazce: co pouzivate/jestli pouzivate na ukladani siti? nejaky spolecny format jako graphml? nebo (jako ja momentalne) je proste ukladate do relacni databaze? pripadne nejake grafove db?

ptam se proto, ze zacinam pocitovat potrebu mit nejaky jednotny format, se kterym budu pracovat ... premyslim o graphml, protoze je to xml, ktery se ztransformovat v pripade potreby, a je podporovano Blueprints (neco jako JDBC pro grafove databaze), takze pak ty grafy by sly i naloadovat do nejakych triplestoru, neo4j apod...

FRAKTALEK: neni. druha veta mluvi o triple storech jako o specializovanych graph databases, coz je treba i ta jena sdb/tdb, o kterych jsi rikal, ze grafovymi databazemi nejsou.
--

uprimne receno, myslim, ze je to uplne jedno. muzeme si kazdy myslet, ze grafova databaze je treba i tuzka a papir, kdyz na to prijde; podstatne spis je, co vlastne BARD chtel delat s grafama, ze se ptal na databazi? ukladat ten twitri cs/sk graf?;)

PAD: myslim, ze to je konzistentni s tim, co rikam:

"A graph database is a database that uses graph structures with nodes, edges, and properties to represent and store information. "

samozrejme na to muzes (a zjevne mas) jinej nazor:
"A graph database is a database that uses graph structures with nodes, edges, and properties to represent and store information. General graph databases that can store any graph are distinct from specialized graph databases such as triplestores and network databases."

Graph database - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Graph_database

PAD: sorry. mel jsem na mysli, ze pokud to omezis na traversing, pak neni graph database, samozrejme (ackoliv s tim nesouhlasim)

jena nepouziva jen relacni databazi (mrkni na TDB) - a higher level api je v podstate stejne (dostanes implementaci Model/u)

SPARQL je taky "v podstate jen" high level pohled na RDF data... - no a? muj point je proste to, ze at uz pouzivas traversing, nebo pattern matching, porad muzes mluvit o grafove databazi - jde jen o to, co potrebujes resit

PAD: teda ty mas zajimavy definice. RDF store je proste neco, kam jdou ukladat RDF data "An RDF store (or triple store) is a system for storing and managing RDF data," http://semanticweb.org/wiki/Category:RDF_store cili Jena urcite RDF store je at je to s traversingem jak chce.

SPARQL je taky "v podstate jen" high level pohled na RDF data...

A jasne, traversing v Jene je pomalej prave proto, ze jena pouziva relacni databazi. Prave proto do toho tady rejpu... Z tohoto pohledu jde totiz o dve ruzne urovne - ta bliz fyzicke vrstve, kde jsou relacni databaze a treba neo4j a kam pro me patri i pojem (opravdove) grafove databaze a pak ta vyssi vrstva systemu typu RDF triple storu (Jena, Sesame, ...), a jinych (InfoGrid, ...), ktere vetsinou pouzivaji nejaky system z te prvni urovne.

FRAKTALEK: pokud definici zusis na traversing, pak jena neni rdf store - zkousel jsem to a je to neuveritelne pomale:)

pattern matching mam na mysli prave sparql - gremlin je v podstate 'jen' high level pohled na pipes/traversing. oboje ma svoje pro a proti - sparqlem muzes pristupovat a dotazovat se rdf grafu jako by to byla relacni databaze, u traversovani zas muzes rychle provadet nektere druhy inferenci (ruzne closures jako coauthorship apod. ..)