2005: 2006: 2007: 2008: 2009: 2010: 2011: 2012: 2013: Jan Feb Mar Apr May Jun Jul Aug Sep Oct (9) Nov (2) Dec (19) Jan (9) Feb (9) Mar (14) Apr (23) May (76) Jun (20) Jul (25) Aug (22) Sep (15) Oct (24) Nov (12) Dec (15) Jan (2) Feb (17) Mar (32) Apr (39) May (38) Jun (11) Jul (19) Aug (39) Sep (33) Oct (61) Nov (67) Dec (90) Jan (47) Feb (67) Mar (112) Apr (39) May (22) Jun (107) Jul (85) Aug (103) Sep (63) Oct (58) Nov (28) Dec (15) Jan (103) Feb (35) Mar (66) Apr (38) May (26) Jun (16) Jul (128) Aug (97) Sep (39) Oct (16) Nov (33) Dec (26) Jan (50) Feb (73) Mar (95) Apr (28) May (60) Jun (76) Jul (78) Aug (54) Sep (55) Oct (25) Nov (74) Dec (36) Jan (25) Feb (57) Mar (109) Apr (68) May (51) Jun (41) Jul (47) Aug (50) Sep (50) Oct (89) Nov (85) Dec (31) Jan (30) Feb (42) Mar (29) Apr (27) May (92) Jun (57) Jul (113) Aug (33) Sep (45) Oct (100) Nov (74) Dec (45) Jan (24) Feb (93) Mar (65) Apr (62) May (100) Jun (64) Jul (25) Aug (44) Sep (24) Oct (50) Nov (173) Dec (31)
S M T W T F S
1 2 3 4 5
(2) (3) (1)
6 7 8 9 10 11 12
(2) (2)
13 14 15 16 17 18 19
(1) (2) (2) (3) (6)
20 21 22 23 24 25 26
(1) (3) (1) (3) (2) (1)
27 28 29 30 31
(2)     (1)
 semediawiki-devel semediawiki-user Nested Flat Threaded Ultimate Show 25 Show 50 Show 75 Show 100
 Re: [SMW-devel] Reflexive results? From: MovGP0 - 2007-05-26 07:24 Sergey Chernyshev schrieb: > Thanks for explanation. I have a couple of comments though: > > On 5/25/07, MovGP0 wrote: >> >> Sergey Chernyshev wrote: >> > Yes, I needed a query that'll work under assumption that "has friend" >> > is the >> > inverse of "has friend". >> There are two ways for doing so. The RDF and the OWL way. >> In RDF you have to make two relations: >> (A , has friend , B) >> (B , has friend , A) >> In OWL you have to define that "has friend" is symmetrical: >> (has friend , rdf:type , owl:SymmetricProperty) >> (A , has friend , B) >> But this comes with the problem that when you define: >> (has friend , rdf:type , owl:SymmetricProperty) >> (A , has friend , B) >> (A , has friend , C) >> It implies that C and B are friends. >> Therefore "has friend" is not symmetrical as you might thought. >> Instead "has friend" is just the opposite of "is friend of". >> The correct OWL-like relation is therefore: >> (has friend , owl:inverseOf , is friend of) >> (A , has friend , B) >> (B , has friend , A) // only if so, because it don't need to be > > > I was talking about this owl:inverseOf type of relation and it looks like > this will solve my problem. > > In SMW there is currently only RDF support. >> What you are missing is the OWL-DL reasoning. >> > >> > I wonder if storing all semantic data in some external storage that >> > supports >> > sparql would be better for SMW. >> Originally it was intended to use the JENA-Framework to do so. >> But the problem appears that JENA is written in Java. >> According to the rules of Wikimedia Java was not acceptable, because >> Java is not really free. >> Its intended to export the propitary database as RDF. >> With these RDF you can import the knowledge into a specialised Semantic >> database like JENA. >> JENA can provide reasoning and SPARQL. >> Later the Export might be done automatically. > > > Do you know if storage and querying interface is abstracted and I can > write > my own store? do you know of any project like that or any other > experience > with it? Export is good, but I don't want to store multiple copies of > data > just to use different querying languages. > > I remember someone suggested using RAP - does this solve the problem? > Is it > reliable direction? I'm not familar with PHP and therefore I'm the wrong to ask about SMW's database bindings or RAP. I'm sure someone else in this forum can lighten this issue. > >> >> > I understand that simple queries need to stay simple but complex ones >> > should >> > still be possible and there is no reason to invent new query language >> for >> > those. >> That's true. >> There is no need to hack the parser. >> The only thing is that OWL-DL reasoning is not implemented. >> This is, because support is currently for RDF only. >> >> I guess it might be a really good thing to implement reasoning into SMW. >> It would be cool if the database layout would implement a new row for >> thracking the origin of a statement. >> Origin | Subject | Relation | Object >> Then you can store from which article a specific statement comes from. >> Using this allows it to find and delete the statements that needs >> updates after editing a article. >> After the old statements are deleted you have to do the reasoning for >> the changed article again. > > > I'm not 100% sure if it's wise for SMW team to concentrate on new storage > engine and querying language - in my view, it's a task bigger then > whole SMW > project. SMW goal of making it usable by regular Wikipedia users sets > some > limitations on syntax and complexity and make this project half baked > unless > it can scale to full version querying language and largest stores - > otherwise it'll be no more then regular Wikipedia categories with a > little > kick. For the moment its not wise, because its most importand to finish. RDF export. But Reasoning and N-ary relations are top priority for future extensions. This issures doesn't change the query language. The additional "Origin" Column will not get exported or change how it looks for the user Its just under the hood to track changes if reasoning is done. > > I'll be happy to discuss the approach where well developed RDF storage > engine is used through an abstract interface and can provide some > _standard_ > querying language (e.g. SPARQL) and SMW maps it's simple query > language to > this standard querying language plus all the functionality of full > featured > query language is available as well (can be limited to administrators if > performance is an issue). > > I believe that being simple but expandable is one of the most important > qualities of RDF and stuff - triples stores versus traditional relational > databases is a huge win in abstraction and possibly scalability, it > makes it > easier to use different tools if standard languages and paradigms are > used. > > I'm really interested in this technology, but it seams that SMW is > currently > not scalable in terms of complexity of information needs and not very > scalable and efficient in terms of storage. I'll need to improve that > for my > project but don't want to dig too deep into application code. SMW's architecture is scalable. For an pure Wiki Administrator its mostly not needed to dig into the source. > > But the biggest problem with reasoning still keeps. >> When you ie. define something like: >> (has friend , owl:inverseOf , is friend of) >> (A , has friend , B) >> (A , has friend , C) >> then you result in: >> (has friend , owl:inverseOf , is friend of) >> (A , has friend , B) >> (A , has friend , C) >> (B , is friend of , A) >> (C , is friend of , A) >> The ammount of information gets nearly doubled with a single line. >> Resoning is not scaleable, which can be a bad thing for a really big >> database like Wikipedia. > > ys, MovGP0 > > > > x*2 data is actually pretty good in terms of scalability x^2 is bad. > > Sergey Do the calc. Assume a set of functions f(x) = g(x) = … = x∙2 representing statements that are doubling the information x. Now use the ring operator h(x) = f∘g∘… = x∙2∙2… = x∙(2^n). You see its doubling with each additional function, wich is the definition of an x². So this is truly bad. ys, MovGP0