Ludovic Dubost wrote:

Artem Melentyev wrote:

...

... I propose:

0) Name: XWiki Query Language, XWQL as a name of the new language.

Why not XQL ? Does it conflict with something ?

XQL is obsoleted XML Query Language (a parent of XQuery). http://www.w3.org/TandS/QL/QL98/pp/xql.html Personally I'm fine with XQL too. But XWQL seems more concrete and doesn't remind XML,XQuery. WDOT?

...

... So the main idea is to use simple JPQL preprocessor to rewrite virtual data model to real. This is quite easy for HQL and JCRSQL2. But it is hard(but doable) for JCRv1 XPath.

I'm not sure we need XPath.. It's deprecated in JCR v2 so we don't really care.

Does this mean our JCRStore need not support JCR1? JCRv2 standard final release planed at Sep-2008. Currently there is some initial (not working) JCRSQL2 parser and (working) QOM in Jackrabbit trunk. Jackrabbit will release as RI with JCRv2. ExoJCRv2 has not JCRSQL2 parser yet, but it planed here: http://jira.exoplatform.org/browse/JCRS Actually, only our query system need JCRv2 features. So I'm writing JCRStore based on JCRv1 standard now. But all queries will work only on JCRv2. (There is queries in xwiki-core, platform-web, all products)

The most important is to have a consitent query api XWQL or XQL working the same way for HQL and JCRSQL2.

-- Artem Melentyev

Jonas von Malottki wrote:

Hello Devs,

by reading that another Question crossed my mind: Have you ever thought of giving XWiki also some semantic capabilities?

I mean the Idea of Semantic Wikis is not new: http://en.wikipedia.org/wiki/Semantic_wiki

In Xwiki you could just put a Link in a 2-tuple form for letting it fulfil the "subject - predicate - object"-Association, with the Subject as the Site where the link is set and the Object the Site where the link is pointing to, so only the predicate is missing.

And sometimes I really think it could make Sense. Especially in Xwiki where you could exploit Information stored that way directly via Scripts and Applications developed in XWiki itself.

The question is not relevant to this topic (Query Language), so you'd better to start new tread. But anyway, there are some effort, I think nepomuk.semanticdesktop.org as possible example. But I don't know much on it. About links, this question to Vincent: can we add some meta data to link? So we can use these links later for semantic needs? :) for example (semantic-mediawiki) http://semanticweb.org/wiki/London : [[capital of::England]] "capital of" is predicate, England is target page. -- Artem Melentyev

Hello Xwikians, Vincent Massol wrote:

On Aug 30, 2008, at 11:56 PM, Artem Melentyev wrote:

...

Jonas von Malottki wrote:

...

Hello Devs,

by reading that another Question crossed my mind: Have you ever thought of giving XWiki also some semantic capabilities?

I mean the Idea of Semantic Wikis is not new: http://en.wikipedia.org/wiki/Semantic_wiki

In Xwiki you could just put a Link in a 2-tuple form for letting it fulfil the "subject - predicate - object"-Association, with the Subject as the Site where the link is set and the Object the Site where the link is pointing to, so only the predicate is missing.

And sometimes I really think it could make Sense. Especially in Xwiki where you could exploit Information stored that way directly via Scripts and Applications developed in XWiki itself. The question is not relevant to this topic (Query Language), so you'd better to start new tread. But anyway, there are some effort, I think nepomuk.semanticdesktop.org as possible example. But I don't know much on it. About links, this question to Vincent: can we add some meta data to link? So we can use these links later for semantic needs? :) for example (semantic-mediawiki) http://semanticweb.org/wiki/London : [[capital of::England]] "capital of" is predicate, England is target page.

The answer is yes. I was about to send a proposal to modify links since I have that need internally in order to support linking to images. The idea is to have this new format:

[[label>reference>property1=value1 property2 = value2...]]

For now the "known" properties would be target and image: [[label>reference>target="_new" image="myimage.png"]]

But it supports any number of properties.

Will that fit your use case?

Yes, indeed it would. The only Thing is that this would not be always easy to understand for the average user (who will use the WYSWIG-Editor) But generally the above Example would translate to: Somewhere on a London Xwiki page: [[UK>United Kingdom>predicate="capital_of"]] (correct ?) In OWL the Fact would be expressed via the triple: "London"-URL "capital of"-URL "UK"-URL All URL whould point to Concepts, while the Capital of Url would point to a Concept that is of the type "Object Property". http://en.wikipedia.org/wiki/Web_Ontology_Language The thing why this came to my mind was, that at some point you would like to ask the Wiki: "What is the capital of UK?". Or in corporate environments maybe: "Who is responsible for Product A?" Surely there has to be done a lot more, specifically in the query language. There are some Research Prototypes in Semantic Wikis, whilst the most appealing Java one seems to be IkeWiki for me now http://ikewiki.salzburgresearch.at/ Another even more structured system is freebase: http://www.freebase.com/view/en/xwiki Maybe it can give a short hinge what is possible and feasible. While I thought Nepomuk just used XWiki for a "CMS" it turns out that they also do research on the topic but I still cannot find any XWiki "branch" there. Greetings Jonas

Hello Marius Dumitru Florea wrote:

...

...

...

About links, this question to Vincent: can we add some meta data to link? So we can use these links later for semantic needs? :) for example (semantic-mediawiki) http://semanticweb.org/wiki/London : [[capital of::England]] "capital of" is predicate, England is target page. The answer is yes. I was about to send a proposal to modify links since I have that need internally in order to support linking to images. The idea is to have this new format:

[[label>reference>property1=value1 property2 = value2...]]

For now the "known" properties would be target and image: [[label>reference>target="_new" image="myimage.png"]]

But it supports any number of properties.

Will that fit your use case? Yes, indeed it would. The only Thing is that this would not be always easy to understand for the average user (who will use the WYSWIG-Editor) But generally the above Example would translate to: Somewhere on a London Xwiki page: [[UK>United Kingdom>predicate="capital_of"]] (correct ?)

The subject, London, is implied in your example. I don't think this is good. What about:

[[London>LondonURL>capitalOf="ukURL"]]

but the predicate is not uniquely identified by a namespace. It would be nice to be able to write:

[[London>LondonURL>o:capitalOf="ukURL"]]

where "o" is defined elsewhere, as the URI of the ontology defining the capitalOf predicate, but I'm not sure this will be supported.

I don't think that would be supported. Since the Links you show are different in the semantics than what Vincent shows. Meaning in the London Page the above link would show to London and not to the UK. Anyway I don't see a problem that London is implied since, every fact you state on the concept page (London) should have by default the subject on the Page. Generally even prefixes are unnecessary unless you import other ontologies. As far as I see it from all the other semantic wikis (also see the mediawiki-example above) the Subject is usually implied. And not implying it would be counter-intuitive for most of the users. The fun part is that after you have those links (and even a link without a predicate can be used as a "is somehow related" default predicate) you can represent them as rdf/owl if the user states so (maybe in the http request). The links then are automatically expanded or prefixed with the configured xwiki base url.

In your example I think you're trying to represent a triple using the link syntax. If you are interested in searching for the capital of UK then a better solution would be to store the triples in a knowledge base (as objects attached to a page for instance) and then just bind the "London" string to the London concept using the link syntax.

Yes and no. Partly because the above explanation of automatic generated rdf/owl representation, but also attaching the facts as Metadata or attached Objects is problematic. From a user perspective it is easy to forget to change the data and then you will have a data quality problem. Also it would mean that you state facts twice: once in the text with a link and another one explicitly in the object/attachment/metadata. Where it is perfectly fine to do it once: in the form of a semantic enhanced link. Take a look at the semantic wiki syntax http://en.wikipedia.org/wiki/Semantic_MediaWiki it is easy to type, implying subjects, embedded and concise. If people understand this and use this, the knowledge base will be build by itself. The only time where I see that the usage of additional metadata is useful is when somebody wants to state for instance that a is equivalent to B or more annotations that are not easily incorporated into the text. Something like the "Facts about London"-Box in http://semanticweb.org/wiki/London (albeit these are generated form the text stated facts). Nice greetings Jonas

Hey Marco Marco K. wrote: <snip>

...

Yes, indeed it would. The only Thing is that this would not be always easy to understand for the average user (who will use the WYSWIG-Editor) But generally the above Example would translate to: Somewhere on a London Xwiki page: [[UK>United Kingdom>predicate="capital_of"]] (correct ?) I highly appreciate the support for semantic links in xwiki. Some months ago, I developed an experimental plugin for this. (With the help of the Graphviz-plugin, I can visualize the relations between pages.) So I have some made experience, I'd like to share with you:

1.) The semantic links should be persistent, so that they can be queried fast, e.g. for lists as in: http://semantic-mediawiki.org/wiki/Property:Located_in http://semantic-mediawiki.org/wiki/Special:Properties Particularly, it should be possible to find all "subject pages" of an object page (as this is done with persistent backlinks in XWiki).

2.) The predicates / properties should have their own document so that you can describe the property or define some "meta properties" there, for example.

Yes. I completely Agree, that would be consistent with the OWL-Way of referring to Data or Object Properties. That would allow to put axioms on the Property Page like "P1 owl:sameAs P2" or whatever.

3.) The value of the predicate should IMHO be also a "fully working" link so that you can navigate to the predicate / property itself. The semantic link should be visible in either way in the generated HTML (at least in the tooltip?). Eventually, the predicate-links should also be stored as backlinks?

The full link would then point to the Property page, or to some property of a another Ontology. But in the latter case the predicate-Links cannot be stored as backlinks. I think it should be possible to write a plugin which would also attach/embed the rdf representation of the Links into the retrieved html page, so that it can be used by foreign systems/programs. This would also apply to the Notation in Wikimodel here: http://code.google.com/p/wikimodel/wiki/AdvancedStructuralElements

4.) Page Renaming of properties should be possible, so that the semantic links are updated with the new predicate.

For my plugin, I used the following syntax - inspired by Semantic MediaWiki [[Space.Predicate::Space.Object]]:

[[Predicat Name>Space.Predicate][Object Name>Space.Object]] or short [[Predicate][Object]]

It had the pragmactic advantage with the old xwiki syntax that the "normal" link parsing and the functions like "Page renaming/Refactoring" work furthermore. From the implementation perspective, I only needed to write a radeox filter that does the following: 1) Read the semantic link and store it in a persistent store 2) Convert [[Predicat Name>Space.Predicate][Object Name>Space.Object]] to [Object Name>Space.Object]. I configured this filter before the XWikiLinkFilter.

My 2 cents.

It is definitely good to hear that other have successfully used xwiki as "semantic enriched"-Wiki and it is thus been tested somewhat. Also I think it is good in terms of Experience. nice greetings Jonas

On Sep 5, 2008, at 4:58 PM, Stéphane Laurière wrote:

Artem Melentyev wrote:

...

Jonas von Malottki wrote:

...

Hello Devs,

by reading that another Question crossed my mind: Have you ever thought of giving XWiki also some semantic capabilities?

I mean the Idea of Semantic Wikis is not new: http://en.wikipedia.org/wiki/Semantic_wiki

In Xwiki you could just put a Link in a 2-tuple form for letting it fulfil the "subject - predicate - object"-Association, with the Subject as the Site where the link is set and the Object the Site where the link is pointing to, so only the predicate is missing.

And sometimes I really think it could make Sense. Especially in Xwiki where you could exploit Information stored that way directly via Scripts and Applications developed in XWiki itself.

The question is not relevant to this topic (Query Language), so you'd better to start new tread. But anyway, there are some effort, I think nepomuk.semanticdesktop.org as possible example. But I don't know much on it.

Indeed, there is some effort on the topic of semantic wikis in the context of Nepomuk. One of the results is the support of semantic syntax in WikiModel as described at [1], and a preliminary WikiModel editor in Eclipse, SWID [2].

The approach is similar to semantic-mediawiki, using a different syntax:

London is capital %capitalOf(England).

The WikiModel syntax also supports block properties:

%worksIn ((( %type [Company] %name Cognium Systems %address ((( .... ))) %description Cognium Systems is a semantic web company... )))

Using this type of syntax, "objects" can be edited as embedded wiki documents.

What I'd love to do in the future is add the ability to represent XWiki document objects using this feature. Once I'm done with all the basic syntax element for the new rendering I'll send some proposal to add semantic properties to documents. Thanks -Vincent

[1] http://code.google.com/p/wikimodel/wiki/AdvancedStructuralElements [2] http://code.google.com/p/swid/wiki/SwidFeatures

Stéphane

...

About links, this question to Vincent: can we add some meta data to link? So we can use these links later for semantic needs? :) for example (semantic-mediawiki) http://semanticweb.org/wiki/London : [[capital of::England]] "capital of" is predicate, England is target page.

Hi, Vincent. Vincent Massol wrote:

...

I would like to discuss about the new xwiki query language. http://dev.xwiki.org/xwiki/bin/view/Design/XWikiQueryLanguage

We need to choose a syntax and data model of the query language

There are some examples in http://dev.xwiki.org/xwiki/bin/view/Design/XWiki+Query+Language+Specificatio...

I already have a prototype based on my JPQL parser (SableCC based

Is that a good parser generator? I know JavaCC and Antlr but have never used SableCC. I'm just worried about us having different parser generators so if we choose one we should try to continue using it across our modules as much as possible. Right now my preference would go to javacc or antlr since they're more well known. Ideally antlr is by far the most powerful but I think it may also be the most complex to use unfortunately.

I'd say it perfect for tasks like this (language preprocessors). Look at http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-query/jpql-parser/src/main/... It contain no code, only EBNF with name labels. And it generates a good AST and visitors for hook and rewrite some interesting places with save all remain input. This is hard to do in other parser generators. It also have CST to AST feature for generate some custom AST, like other parsers do. According to use different parsers, SableCC and xwql has no affect on other modules. SableCC has no runtime dependency (in contrast of antlr). So I think it is ok for use SableCC for xwql. I agree that antlr is most powerful. But it requires much more hand work. (create and generate AST) PS: Also, SableCC is LALR(k) parser, means it is more powerful in grammar sense than LL(k) without lookahead.

...

example: "select doc.fullName from Document as doc, doc.XWiki.XWikiUsers as user where user.email like '%xwiki.com' and doc.author=:username"

"select doc.fullName from Document as doc" may be omitted. It will be added if there is no Document in query statement. So "from doc.XWiki.XWikiUsers as user" is correct query statement.

I don't like the mix of semantics between doc.fullName for example (which represents a property of a document - a field in the DB) and doc.XWiki.XWikiUsers which represents an object of a document. I don't think they should be at the same level and the usage of "." in the object name is confusing (and may also confuse the parser).

I'd prefer something like: doc.objects(XWiki.XWikiUsers) or doc.objects("XWiki.XWikiUsers").

Then we can add: doc.attachment(attachmentName) and doc.class later on.

WDYT?

"doc.XWiki.Class as obj" has the same sense as "object.list as listitem" in JPQL. 'XWiki.Class' is a part of document. It is not a single field, but a virtual collection. But I agree, there is conflict possible with objects and other parts of document (attachments, class) so we need some prefix. And you variant is quite good. It eliminates the problems with special chars in document names. so +1 to doc.objects(XWiki.Class). "" is not needed IMO. Parser can take care of special chars in this case too, i think. WDOT? PS: another variant: from Document as doc, doc.objects as obj where obj.class='XWiki.Class' more universal, but less readable and hierarchical.

...

...

-- Artem Melentyev