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
>>> **************************************************
>>>
>>>   
>>>
>>>
>>> David Karger wrote:
>>>     
>>>       
>>>> David Huynh wrote:
>>>>   
>>>>       
>>>>         
>>>>> Rob wrote:
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>>>> Hey,
>>>>>>
>>>>>> I am in the process of creating an exhibit which highlights all the
>>>>>> eateries on the MIT campus. Right now, I'm trying to think of
>>>>>> classifier values that will allow users to filter through these
>>>>>> eateries.
>>>>>>
>>>>>> This is what I have so far:
>>>>>>
>>>>>> American, Breakfast, Bakery, Cafe, Catering, Deli, Desert, Dinner,
>>>>>> Ethnic, Grocery, Healthy, Lunch, Made on Order, Mexican, On the Go,
>>>>>> Pizza, Prepared, Pub, Soup, Sit Down, Sushi, Vegetarian
>>>>>>   
>>>>>>     
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> That sounds like "cuisine".
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>> Actually I would break it down further, into e.g. cuisine (american,
>>>> mexican, sushi), meal (breakfast, lunch, dinner), preparation (made to
>>>> order, on the go, prepared...)
>>>>
>>>> You might also look at this exhibit for some ideas:
>>>> http://gvn.rhizomatics.org.uk/glasgowguide.html
>>>>
>>>> (which is on the examples page at
>>>> http://simile.mit.edu/wiki/Exhibit/Examples , which should really get
>>>> migrated to the new wiki).
>>>>   
>>>>       
>>>>         
>>>>>   
>>>>>     
>>>>>         
>>>>>           
>>>>>> I'd appreciate any suggestions you have that would help filter the
>>>>>> eateries even more.
>>>>>>   
>>>>>>     
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> How about...
>>>>> - price range: $, $$, $$$,... or, $10 - 15, $15 - 20, ...
>>>>> - delivery?
>>>>> - open hours
>>>>> - accept credit cards?
>>>>> - geolocation
>>>>> - health rating
>>>>> - free wi-fi?
>>>>> - has vegetarian dishes?
>>>>> - has student discount?
>>>>> - ambiance
>>>>> - how many T stops away, distance to closest T stop
>>>>>
>>>>> David
>>>>>
>>>>>     
>>>>>         
>>>>>           
>>   
>>     
>
> >
>   

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to