Actually, I'd rather take down my Exhibit completely and a new Exhibit put up on simile-widgets.org. If the Wibit data repository of SIMILE resources that Fabian created will remain supported (and editable), then I'd like to take down my Google spreadsheet as well. No reason to have two. I'll help where I can.
I agree that Wibit is a more natural and better looking UI than Google Spreadsheet, especially for Mediawiki users. Whether it's a better data repository or not depends on the purpose of the data. (of course, SMW is very likely better in most cases.) - John David R. Karger wrote: > One other thought. I'm pretty convinced that the SMW provides a better > _data_ repository than a google spreadsheet, independent of the question > of whether it provides a better visualization repository than the > alternatives. In particular, it provides a more natural UI for someone > who wants to add/modify information about a particular resource (and a > nice place to look at the detailed information about one such > resource). So, I'd advocate that your current exhibit point at the SMW > repository (using the jsonp technique fabian outlined) for its data, > even as we continue to consider the right location for the > visualization. What do you think? > > John Callahan wrote: > >> Very cool to see the list of SIMILE resources on Wibit! (or should I >> say "a wibit"?) It looks good. You can easily see how more complex >> Exhibits may require the JSON exporter vs the ask query. Obviously, one >> concern would be the extra processing required hurting performance. >> Probably negligible for most cases. Who knows how Exhibit (or SMW ask >> capabilities) will change in the future. >> >> >> Thanks for all the details and clarifying a few points. Good reading. >> >> I agree it's an interesting question about bringing Exhibit's features >> into the wiki world. I see RDFifying mediawiki content as essential. >> Along with that is structured editing forms and flexible tagging. And >> serving that data in various ways is important, like the JSON exporter. >> (I'd maybe also argue for better URL creation per page.) However, >> these are data/content features and not in displaying relationships, >> where Exhibit lies. Of course, if the data is structured properly, why >> not just through in an "Exhibit plugin" for displaying that data? :-) >> >> >> It's definitely a convenience for wiki users to create Exhibits from >> their SMW content. There's such a large user base. I'm not sure how >> important that convenience is, except for promoting SIMILE and making >> easier to use displays for people. You have to weigh that against your >> time (for development and continued maintenance) and the level of >> commitment from any community that may develop around it. If someone >> wanted a site for structured data through semantic web technologies, >> with various RDF data displays (like Exhibit and others), I'm just not >> convinced that a wiki site is the way to go. >> >> - John >> >> >> >> >> Fabian Howahl wrote: >> >> >>>> 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. >>>> >>>> >>>> >>> Indeed the lack of certain Exhibit features is an issue right now. >>> I imported the Simile resources into our Wibit wiki and tried to >>> recreate the existing Simile resources exhibit >>> (http://geo42.com/sites/simile/resources.html >>> ) as far as possible: >>> http://projects.csail.mit.edu/wibit/wiki/index.php?title=SimileResources >>> A look at the wikitext of the page reveals that the resulting exhibit >>> is configured within an ask query. The configuration via ask >>> parameters yields the mentioned limitations, although the >>> configuration turns out to be fairly easy. That's why the result of >>> this ask query does not resemble the existing exhibit completely. Some >>> things are predefined and therefore can't be changed through ask >>> parameters (such as the alignment of the views and facets), whereas >>> others cannot be carried out due to the missing support of certain >>> Exhibit features (e.g. the result printer supports lenses, but no >>> collections). >>> >>> However, to circumvent these limitations, one can always use the JSON >>> exporter to feed an usual exhibit that is configured with HTML in >>> order to be able to leverage Exhibit's total power. >>> >>> Anyhow, it is a fair and interesting question whether it is worthwhile >>> to bring all of Exhibit's features to the wiki world. I started with >>> extending wikitext by counterparts to the HTML constructs (due to the >>> MediaWiki Sanitizer it is not possible to embed Exhibit HTML tags >>> directly). This led to the introduction of various new parser >>> functions, which tends to confuse wiki users. Apart from that, many >>> users certainly wish to use all of Exhibit's features. It is kind of a >>> dilemma. >>> >>> I'd be happy about any comments on this. In particular, I'm really >>> curious what functionality you miss the most in the Exhibit result >>> printer. >>> >>> >>> >>> >>>>> 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. >>>> >>>> >>>> >>> By all means, I would recommend to use Semantic MediaWiki right from >>> the start (it is mature and approved). Then you have the choice of >>> using extensions such as the Exhibit Result Printer and Semantic Forms >>> (the JSON exporter comes with SMW either way). These extensions are >>> not likely to harm the Semantic MediaWiki so that you can experiment >>> with them. >>> >>> >>> >>> >>> >>>>> 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) >>>> >>>> >>>> >>> I agree. If one has a certain level of MediaWiki knowledge it is quite >>> easy to use. >>> I would say, if one knows what a MediaWiki template is the setup >>> procedure won't be a big deal. >>> >>> >>> >>> >>>>> 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 >>>> >>>> ) >>>> >>>> >>>> >>> Another selling point of SMW is the possibility of RDF exports. So you >>> can browse the SMW content with the aid of Tabulator, for instance. >>> >>> >>> >>> >>>>> 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. >>>> >>>> >>>> >>> These features are mostly covered by the Halo extension >>> (http://semanticweb.org/wiki/Halo_Extension >>> ). Furthermore, SMW comes up with some special pages allowing the user >>> to browse the vocabulary. >>> >>> >>> >>> >>>>> 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. >>>> >>>> >>>> >>> As follow-up to >>> http://www.w3.org/TR/2007/WD-xhtml-rdfa-scenarios-20070330/#use-case-6 >>> Google's Summer of Code 2008 contained a project on this: >>> http://labs.creativecommons.org/2008/07/01/rdfa-for-semantic-mediawiki-gsoc-2008/ >>> >>> >>> >>> >>> >>>>> Google's new Rich Snippets (and other semantic search engines) >>>>> could take advantage of it. >>>>> >>>>> - John >>>>> >>>>> >>>>> >>> -Fabian >>> >>> >>> >>> >>> >>> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
