Thanks for explanation. I have a couple of comments though:

On 5/25/07, MovGP0 <movgp0@gmail.com> 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 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.

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.

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