[Sorry for long email. I'm working through the argument as well. We have similar types of conversations around here with different CMSes, learning systems, SharePoint, and static Dreamweaver developed sites.]
Do we *need* the power of a CMS for SIMILE documentation and metaexhibit? No. What we have now works fine. However, I *want* to make things easier for users of these sites. I want to see relationships among all the doc pages and/or resources/examples in the metaexhibit. I want to have the flexibility to tag and organize the information as I like. I want feeds and the flexibility to query the data as I like, and to do it easily. I want to see more related information on a page I'm reading then just the page itself. A CMS is designed for this purpose. Structured data is necessary for this, and that's not a bad thing. Personally, I'd like to see the SIMILE projects grow. I'd like to see a site with News/Announcements (in addition to the emails) with maybe a blog or tutorial videos. I'd like one site with loads of information of all types. I'd like to see a conference or meet-up, even a virtual half-day webinar with a handful of presentations would be great. I'd like to have a site displaying feeds from semantic web news sources or about current web trends. I don't know if our community is large enough to support these ideas but you never know... Do we need a CMS? No. Do I want one? Yes. I find them useful for these types of sites and has the flexibility to grow. (This could very well be just me :-) or a minority of the group.) The question comes down to sacrifices. Are the server admins and project leads willing to manage a CMS over a simpler wiki package? What's the benefit and to who? Community members can help with support, design ideas, content, etc... but it's ultimately a private decision. I would argue that the power of a CMS comes with what you do with that structured data. Why else would be structure your data in the first place? Likely it comes down to priorities. It seems Mediawiki focused on the collection of data. SMW adds structure to that data plus some limited manipulation. A CMS has always focused on the manipulation of data (structured or not) and its collection interfaces (web editing, feed ingestion) have changed significantly over the past few years. A CMS is more powerful but you pay in server admin and maintenance. Even here, this is getting easier for CMS and possibly more sophisticated with SMW and mediawiki extensions. I would agree that a CMS and SMW have an increasing number of features in common, with results converging in the center. Drupal is essentially a framework of APIs and couldn't care less about the front end. It really only has one data model called a node. I commonly just delete the default node types (page, story) and create my own structure with CCK. I agree Drupal has always been about structured data and it's functionality is tailored to it. The structure is just becoming more user defined, probably very similar to SMW. I've had the same gut instinct that a CMS is overkill for certain situations. One example is that we had a 6 person committee and we wanted to share notes. Nothing special. A wiki (not sure which sw) was the first idea. However, I setup a Drupal site for them and it works great. Very little maintenance since I started it 6 months ago. Not sure what I was worried about at the start. Nearly anything interesting you want to do with Drupal requires enabling a module. Drupal is extremely modular and very dynamic! It does get tricky determining which modules are best. They have their own strengths/weaknesses and are always changing. For me, finding the right module is a BIG deterrent to Drupal (I'm actually hoping they use something like Exhibit to sort through al lthe modules, of course, there are 4500+ of them!) You mentioned that you have had to hack PHP with Drupal. Was that to apply interim patches or to change functionality? I'm curious because I maintain about 12-15 sites and rarely have to modify PHP. - 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: > 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 -~----------~----~----~----~------~----~------~--~---
