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. ..)

PAD: no nevim..to je trochu moc siroka definice, ja beru grafovou databazi jako typ nosql databaze, ktera je optimalizovana prave pro traversing. A pro traversing neni neo4j lepsi asi ale urcite.

U pattern matchingu asi zalezi, co mas presne na mysli. Pokud vim, tak treba SPARQL ma v tomhle ohledu dost omezeny moznosti a daleko vhodnejsi by asi byly ruzne RDF Path jazyky, ktery zase bezne nejsou implementovany. A na druhou stranu, pro neo4j existuje treba ten Gremlin...nezkousel jsem, ale v tom asi pujde udelat hodne.

Podle me, pro implementaci grafovych algoritmu (DFS, BFS, jakykoliv jiny traversing) je jednoznacne lepsi Neo4j nez Jena, ktera pokud vim pouziva relacni databaze (in memory nepocitam, tam si muze delat kdo chce co chce, o tom se nebavime).

FRAKTALEK: jasne, je to vec terminologie. RDF je graf, databaze, ktera uklada graf, je grafova databaze, Jena story (RDB, SDB, TDB) ukladaji RDF, takze jsou grafove databaze. prijde na to, jaky graf ma clovek na mysli a co s nim chce delat (pattern matching - vetsinou lepsi RDF story, traversing - asi lepsi Neo4J apod.)

PAD: Jenu bych nepocital mezi grafove databaze

BARD: s neo4j, ale spis jednodussi veci

BARD: mam, trochu s neo4j, a vetsi s Jena SDB (RDF store)

Mate nekdo nejake zkusenosti s nejakou GraphDB? Jde mi o to, ze seznam ceskych a slovneskych Twitter uctu mi prijde jako prima zacatek pro datamining Google Social Graph API a s tim nastupem otazek typu okolni kamaradi, vazby mezi blogy a podobne.

Nastesti mam virtualni masinu s Linuxem, ale ten cas nemam:-(

BARD: mně to při prvních pokusech z osx házelo seg.fault.. což není dobrá zpráva.

pocitam, ze s k tomu dostanu pred Berlinem

BARD: to vypadá luxusně!

PAD: vypada to tak, krom toho by si to prej melo poradit i s velkejma sitema

BARD: nebylo a uz jsem na to narazil, ale nejak sem na prvni pohled (letmy, pravda) nepochopil, v cem spocivaji vyhody ... ale musim se na to mrknout poradne. ten tym se zda hodne silny ve vizualizaci komplexnich systemu ...

PAD: tak celej ceskej a slovenskej twitter neco zaber:-) Btw: tohle tu bylo? http://mkweb.bcgsc.ca/linnet/img/network-communities.png Vubec ty stranky vypadaj dobre: http://mkweb.bcgsc.ca/linnet/

BARD: to je pekne husta sit! nedavno jsem vyzkousel gephi na macu a site, ktere mi pod linuxem trvalo vyrenderovat vecnost byly hotove za par sekund (okol 3k uzlu, asi 100k hran). tak treba by to slo i s vetsimi sitemi. pokud ne, tak pak uz asi jedine neco napsat - pokud nechces vyslovene neco hackovat v cecku nebo jave, tak doporucuje se podivat na R a balik igraph. pripadne exituje i pro python, ale v R jsem behem asi 30 minut byl schopny sit natahnout do pameti a vyrenderovat - zkratka je to spis prostredi urcene pro statistiky prip. spolecenske vedce, nez pro vyvoj aplikaci.

TLAMPAC: ano, bohuzel ano