We are looking for a lightweight solution to prove the concept.  Right now the CMS back end we have doesn’t have a user interface.  By the way, we looked at Plone initially and liked it for several reasons but there were some hurdles that we just didn’t want to try to take on.  MW/SMW have lots of nice displays too, just not anything revolving around collections.  I’m not familiar with External Store but am now looking at the code.  I’ll have to look and see how its used.  I assume that “data” in this case refers to files/content since there is an http implementation.  Can this be used in conjunction with the filerep classes?  If so, it sounds promising.  I too am concerned that it might require a lot of low level changes but am hoping to find a good/clean way.   

In looking at the semantic image gallery, it uses the ImageGallery class.  Image pages are added to to the image gallery based on hits from the query and these are represented as File objects with methods to get thumbnails and so forth.  So a mechanism to generate File objects that can point to our data and provide all the normal behavior would seem to be one way to minimize the amount of code that has to be modified.  Perhaps we could have a special File subclass that knows about our repository but I’m not sure how/where to hook something like that in.  It might become more clear if I look at how ExternalStore is used.  Does that make sense?

Any overview documentation on filerep and the various storage dirs/classes would be helpful if you are aware of any.

Revisiting my original question, is the Store API the right thing to use for my queries and if so, any idea why I was not getting all the data I was expecting.    


On 10/9/09 2:16 PM, "Yaron Koren" <yaron57@gmail.com> wrote:


The concept of MediaWiki supporting a hierarchical file structure, although it (a) seems like it might be a rather dramatic change to MW, requiring a lot of low-level changes, and (b) seems only tangentially related to SMW. Sure, you might want to have a new special property or two, along the lines of "Modification date", but that's not really the core issue.

With that said, maybe there are less dramatic, more lightweight solutions to get at the same issue. For instance, if a CMS like Plone already supports file versioning of the kind that you require, maybe it's possible to have a lightweight extension, akin to External Data, that can (a) display an image/file from that CMS, (b) retrieve other data about that file, that can then be stored via SMW, and (c) link the user to the CMS's interface for dealing with that file. It could be called "External Files", perhaps... any thoughts?


On Fri, Oct 9, 2009 at 4:23 PM, Schuchardt, Karen L <Karen.Schuchardt@pnl.gov> wrote:
Hi Yaron,

We want a CMS that versions file sets (not just individual files), provides the normal hierarchical file structure people are familiar with (not just namespaces), and then we want to make views of the content based on both the collection hierarchy and semantic queries for metadata we extract from files.  Ideally, we want the best of something like MW and Plone which provides flexible views of content.

In addition to the image gallery, we plan to integrate different types of custom viewers along the lines of the gnu plot extension, statistical operations on data etc.  Basically we want to be able to plug in a range of data operations on the server side.  

The number of files will be large and some of the files will be large.  We also plan on providing provenance information between files or collections of files.  The data is scientific data.  Some ascii, some binary.  Lots of different formats.

The images and other data will effectively be located on the server in a normal file structure so that MW/SMW can easily access it though it might be deposited through other means than the wiki.  We currently have a wiki upload extension that takes a zip file, unzips it, add the data to the CMS, and generates the façade pages.  Command lines tools for doing this same thing will also exist.  Now we are investigating how to integrate it more deeply in the wiki presentation.

Does that answer your question?  We really think this could be a powerful capability for collaborative science but are in the infancy of figuring out what it would really take to do it well.  Any suggestions or information will be very helpful to us.


On 10/9/09 1:07 PM, "Yaron Koren" <yaron57@gmail.com <http://yaron57@gmail.com> > wrote:


Can you clarify what it is that you're trying to do? You said that you wanted to turn SMW into a CMS (it already is one, of course, but it certainly could be a nicer one), but then you mentioned using "images from our CMS". Where are these images coming from? And what features, if any, do you want to add besides external-image integration?


On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L <Karen.Schuchardt@pnl.gov <http://Karen.Schuchardt@pnl.gov> > wrote:

We are interested in augmenting SMW/MW to have a more sophisticated content management capability so that it can act as a Content Management System (CMS) with great wiki features.  Our approach so far has been to generate a façade page for every document/collection that gets loaded into the CMS.  These façade pages are essentially metadata pages that contain semantic markup about the contents of the files.  They also support normal directory navigation.  I’m trying to get a handle on the best way to change the existing SMW code and extensions so that they “know” about our files.  I hope you can offer some advice.

As a first example, I’m looking at modifying the semantic gallery so that it can display images from our CMS.  The semantic markup that we add to each file facade includes properties for mimetype and a reference to the actual file.  But I don’t want the ask query writer to think about such things so I would expect a normal image gallery query to be supplied.  That implies that in my output formatter, I would get hits on the image façade pages and have to do two things:
  1. for a page hit, ask for more data about the page (additional properties we have added (mimetype,fileuri))
  2. somehow replace some of the filerepo code to be able to locate files

The latter is more of a MW issue I believe.  But for the 1st item, the documentation says to use the SMW Store api.  However I notice that most extension code uses direct DB calls.  Is it still the case that I should be using the Store API?  I have started down this path as it seems like the correct thing to do.

I have tried to use the Store API like this:
      $data = smwfGetStore()->getSemanticData($title);
      $properties = $data->getProperties();
      foreach ($properties as $property) {
         $rv = $property->getWikiValue();
         //$proptext = $property->getLongHTMLText($skin);
         $values = $data->getPropertyValues($property);
         $count = count($values);
         foreach ($values as $value) {
            $valu = $value->getShortWikiText();

What I’m getting back is the modification time and an initial category I used for the page.  I added more properties and another category and they don’t show up in the query result but they do show up in an ask query.  I tried to update the cache with a action=purge

Am I approaching this wrong or using the wrong method?  We are using the HaloStore2 I believe but the method is implemented in sqlstore2.  I have not sifted through all that code but at first glance, it looks like its looking for a well-defined set of properties.  Is that correct?

Any pointers greatly appreciated.


Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net <http://Semediawiki-devel@lists.sourceforge.net>