I'm a big user and fan of drupal myself, maintaining a couple of sites. And on one of them, I jerry rigged some exhibit technology before it officially got integrated into Drupal. But when I weigh them for this particular application, I come down on the side of a wiki rather than a cms. My intuition is that a CMS is actually overkill for what we want to do. That's may sound a perverse, given that our goal appears to be managing some content. Right now this is only an instinct. Formulating a precise understanding of the issues is right in the middle of my research agenda here at MIT. But as a first cut, let me suggest that drupal and semantic mediawiki are coming at the same problem---that of general structured content management---from two different sides, converging towards a center. Drupal started as a management system for specific types of highly structured content---nodes, stories, comments. It has attempted to generalize to other types of content through the CCK extension, but it still really privileges the core types. Wikipedia started with no specific content types, but also no structure. Semantic mediawiki has tried to bring a more structured model to the wiki space, while preserving the non-domain-specific nature of the content it manages. Backing this up, I have generally found that any time I want to tweak the management of a certain kind of content in Drupal, I have to go hack php. In wikis, people don't write modules for specific content types; they write modules for certain behaviors over all content types. I think this is a more fruitful line in the long run, unless you really need to manage a specific content type in a specific way. I don't see any domain-specific content-management functionality that we need for the metaexhibit, so I don't see a need for the power of a CMS. And that means I can safely avoid the complexity of the CMS (compared to a wiki).
I still need to flesh this argument out, and welcome comments on it. -David John Callahan wrote: > Thanks David. Sounds interesting. I need to read more about the > capabilities of SMW and Wibit. > > One question: could Drupal be an option for the SIMILE wiki > documentation and resources site? I've been using it for nearly 2 > years now and it can do just about everything we need it to. It can > support Mediawiki syntax (or Markdown, or basic HTML, or WYSIWYG, or > ...) It's easy to create page editing forms, tags/vocabs, feeds, > dynamic navigation tools, etc.... Completely customizable in the > layout/style as well, if that's an issue. > > There's also plenty of semantic web technologies in there, from the RDF > and SPARQL projects/modules, to Exhibit feeds and display, to RDFa in > core Drupal 7. > > http://openspring.net/files/rdfa_drupal_cheese_sfsw09.pdf > http://www.cmswire.com/cms/web-cms/rdfa-drupal-and-a-practical-semantic-web-004149.php > http://groups.drupal.org/semantic-web > > > I'm not knocking SMW/Wibit in any way. In fact, I think they're great > and bring the power of the semantic web/Exhibit to a large base of > Mediawiki users. However, since we are essentially re-organizing, and > for the current needs of a documentation/resource site, a CMS framework > like Drupal could do a good job. (Drupal runs on apache/mysql/php, I > believe the same as Mediawiki.) I'm sure Drupal takes more setup than > Mediawiki and probably more maintenance (security patches are usually > monthly or bi-monthly.) > > > Just a thought... I'll help wherever I can. > > - John > > ************************************************** > John Callahan > Geospatial Application Developer > Delaware Geological Survey, University of Delaware > 227 Academy St, Newark DE 19716-7501 > Tel: (302) 831-3584 > Email: [email protected] > http://www.dgs.udel.edu > ************************************************** > > > > David Karger wrote: > >> John, I'm CCing Fabian, who did this SMW-exhibit integration work while >> he was visiting me last year. Hopefully he can contribute some >> additional answers and assistance. >> >> John Callahan wrote: >> >> >>> Perfect. Thanks for the link and the project. I actually ran into SMW >>> while looking for better ways to tag the SIMILE examples in Mediawiki >>> when I first started moving them over. Yes, I think it's an excellent >>> idea and could be extremely useful if it's flexible enough. (One of the >>> primary reasons I use Drupal is the amount of control I have over the >>> format/tags of user input as well as customizable query/feed/display >>> options.) >>> >>> >>> >>> >> Well, the level of customization is exactly what I was referring to when >> I said we were trying to polish a few more things before >> announcing/pushing wibit. Right now, there are some limitations on >> layout to keep the syntax for specifying the exhibit simple. >> >> >>> From a quick look, the first thing that comes to mind is to use Wibit >>> for all of the SIMILE wiki documentation. Pages from old MIT wiki and >>> the new Mediawiki wiki could move to a new instance of Wibit. (I still >>> need to read more closely on the differences between the Exhibit Result >>> Printer and JSON Exporter.) >>> >>> >>> >> I think this could be a great idea. However, it may be risky---we >> haven't seen a lot of use of Wibit yet, and there could be horrible >> problems lurking inside. It would be great to have people give it a >> workout for a while with some specific collections, to reveal such >> issues before we consider a wholesale migration. In particular, the >> metaexhibit seems a great starting point since it is so clearly structured. >> >> >>> How easy are the page edit forms to create? >>> >>> >> this actually isn't exhibit, it's the semantic forms extension for SMW. >> Documentation is here: >> http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Structure >> with specific syntax here: >> http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Defining_forms >> >> I think it's about as "easy" as using other complex mediawiki markup >> (translation: mediawiki users are happy with it, but the rest of us >> probably find it rather arcane) >> >> >>> You would likely need >>> several forms for different types of content each with their own >>> vocabularies. >>> >>> >> Yes, there's a one-form <====> one data type pairing >> >> >>> Can you use controlled vocabs as well as free tagging? >>> >>> >>> >> Yes, the form can contain dropdown menus for selecting from a controlled >> list. Go to the Wibit "beer" exhibit at >> http://projects.csail.mit.edu/wibit/wiki/index.php?title=Beers , >> click on a beer >> http://projects.csail.mit.edu/wibit/wiki/index.php?title=Augustiner_Edelstoff >> , then click the "edit with form" tab to go to >> http://projects.csail.mit.edu/wibit/wiki/index.php?title=Augustiner_Edelstoff&action=formedit >> . You'll see a drop down menu for selecting Beer type and brewing month >> from a controlled list. >> >> >>> And multiple vocabs per form/template? >>> >>> >> not sure what you mean by this. Each form reflects the vocabulary >> you've chosen for that data type. >> >> >>> >>> >>> Also, once pages are created and tagged, are there ways other than >>> Exhibit to search/browse through the data? >>> >>> >> well, one can emit the data as jsonp for use in other tools >> (http://projects.csail.mit.edu/wibit/wiki/index.php?title=Making_exhibits_from_data_of_Semantic_MediaWikis) >> >> >>> For example, such as >>> creating dynamic menus based on a single (or multiple) vocabularies? Or >>> an auto generated sitemap? Or something like a table of contents or >>> glossary index? >>> >>> >>> >> These I'm not sure about and will defer to Fabian. They are certainly >> neat ideas for addition if not already there. >> >> >>> Are the pages in SMW actually marked up with RDFa as defined in the edit >>> form? >>> >>> >> Not that I know of (SMW preceded rdfa). Again, a nice idea. I wonder >> if the lens framework, or the infobox template for each item type, could >> be used to create that rdfa on the fly as part of the page. >> >> >>> Google's new Rich Snippets (and other semantic search engines) >>> could take advantage of it. >>> >>> - John >>> >>> >>> >>> David Karger wrote: >>> >>> >>> >>>> John, this is a really nice piece of work. But I think a potentially >>>> better way to host this data (because it makes it easy for anyone to >>>> edit) is in a fully exhibit-enabled wiki. We've got one here: >>>> http://projects.csail.mit.edu/wibit/ >>>> It's actually a semantic mediawiki, which adds some interesting >>>> capabilities. In particular, as you suggest below, you can create a page >>>> for each resource with useful text and metadata (and create a form for >>>> editing the data on such pages), which would then be aggregated into the >>>> exhibit, but could also be emitted as json for someone else to use in >>>> another setting. >>>> >>>> We've wanted to do a bit more tweaking before suggesting this be used as >>>> a repository of exhibit resources, but since you've already taken the >>>> leap, would you like to take a look and think about whether it would be >>>> an effective repository? I can help you figure out how to use it if you >>>> need. >>>> >>>> -David >>>> >>>> John Callahan wrote: >>>> >>>> >>>> >>>> >>>>> I had started to migrate the examples from the old wiki and elsewhere >>>>> on the web over to the new wiki. While doing so, it made sense to me >>>>> to include other resources, like blog posts or third-party apps that >>>>> make use of SIMILE widgets. It also made sense to include information >>>>> from all SIMILE projects. So, I created an Exhibit (powered by a >>>>> Google Spreadsheet) of all the resources I found and linked them from >>>>> the new wiki home: >>>>> >>>>> >>>>> http://www.simile-widgets.org/wiki/ (up to 153 resources!) >>>>> >>>>> >>>>> A few thoughts... >>>>> >>>>> 1. It would be nice if this Exhibit was not on my server (geo42.com) >>>>> but rather directly on simile-widgets.org. (and styled a bit nicer as >>>>> well!) I've tried a few things to add the necessary javascript >>>>> components to the wiki but I do not believe I have permission to do >>>>> so. Is this something worthwhile to add to the main s-w.org site? >>>>> >>>>> >>>>> 2. Using a Google spreadsheet is the best way I know for community >>>>> maintenance of this data. It's easy to turn into a JSON feed as input >>>>> to Exhibit. My first thought was to create a new wiki page for each >>>>> resource, tag it sufficiently, then somehow generate a JSON feed with >>>>> all the appropriate tags as attributes. I can do this in Drupal but >>>>> couldn't figure it out with Mediawiki. (that method is probably >>>>> overkill anyway.) If necessary, does anyone have another idea >>>>> besides a Google spreadsheet? (of course, a custom PHP/MySQL app >>>>> would work if anyone wants to code it up.) >>>>> >>>>> >>>>> 3. The attributes in the spreadsheet are very limited: title, >>>>> description, SIMILE project, type of resource, In The Wild or >>>>> homegrown, does it include a map, does it include a graph, and URL. >>>>> Of course, it'd be nice to have things like a screenshot image, the >>>>> software version, features used, date published, person/org, etc... >>>>> However, IMO, this information would be difficult to maintain. As >>>>> well, I don't know how to find that information easily for many of the >>>>> entries. Although some info *may* be better than none. Any >>>>> thoughts here? >>>>> >>>>> >>>>> (Wouldn't it be nice to have a script that went through the URLs of >>>>> each resource, tested the URL to make sure it's alive, and parsed the >>>>> HTML/javascript code to determine which SIMILE product it's using and >>>>> what features are enabled? :-) ) >>>>> >>>>> >>>>> - John >>>>> ************************************************** >>>>> John Callahan >>>>> Geospatial Application Developer >>>>> Delaware Geological Survey, University of Delaware >>>>> 227 Academy St, Newark DE 19716-7501 >>>>> Tel: (302) 831-3584 >>>>> Email: [email protected] >>>>> http://www.dgs.udel.edu >>>>> ************************************************** >>>>> >>>>> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
