[grubstreet] Hackfest report

[prev] [thread] [next] [lurker] [Date index for 2003/4/22]

and the software seen in action at
  http://un.earth.li/~kake/cgi-bin/wiki.cgi

(That tarball is now fixed - any updates from now on will have a
 different version number.  The software in action link is my
 development site though so may change and break.)

If you download the tarball and install it using the instructions in
README, it will ask you questions about config details, and then
install itself as an instantly working OpenGuides wiki.  It currently
only works with postgres but it won't be hard to make it work with
MySQL and SQLite as well, since CGI::Wiki supports both of those fully.

The main thing now stopping us moving grubstreet over to OpenGuides is
that CGI::Wiki's list_recent_changes method is too slow when the
number of nodes in the wiki is large.  With the 800-odd nodes in
grubstreet, it's unacceptably slow.


*****  The single most important thing anyone can do at the moment  *****
*****  if they want to progress this project is to improve the SQL  *****
*****  in CGI::Wiki::Store::Database::list_recent_changes so it     *****
*****  scales better.                                               *****


That's emphasized because although it's great to have all these ideas
about new features to add, we're quite amply featured up at the moment
and we need to sort this problem before we go live.  I will of course
be working on it, but many eyes make shallow bugs, etc, etc, and
probably someone else on this list is better at SQL than me.  (Putting
an index on the metadata table might well help.)

Again, that issue is the *only* one stopping us going to staging
(which I see as a parallel wiki running on grault.net that we all
agree to use instead of grubstreet for a testing period).

Kake

----------------------------------------------------------------------

Whiteboard transcriptions:

Task List

 - Earle to look at Kake's template changes
 - Look into modifying RDF to use PIM/contact instead of ChefMoz for
   address information
 - ChefMoz only for food nodes
 - Kake to put OpenGuides on the.earth [in progress, have mailed sysadmin
   to ask for a new database]
 - Activate "Utilities" link in side navigation [done, is now a link to
   preferences.cgi and titled "Set username/preferences"]
 - CGI::Wiki::Formatter::UseMod - write node_name_to_link method (for
   Ivor's supersearch)
 - Build.PL - bail if prereqs not found?
            - make config stick around for next install
            - editing wiki.conf doesn't affect the install dir and should
              (or should be documented)
 - Earle to check whether geo:lat and geo:long are defaulting in the RDF
   [yes, they are - OS X and Y are defaulting to (0,0) which is a valid
    point with lat and long]



RDF Consultation with mattb

 - "Sesame" RDF query engine - needs java to run.  MattB will advise
   further next week.  Example:

       select ?place,?title
       where (?place,<chefmoz:Neighborhood>,"Holborn"),
             (?place,<dc:title>,?title)
       using chefmoz for <http://chefmoz.org/rdf/elements/1.0/>;,
       dc for <http://purl.org/dc/elements/1.1/>;

       "find me a place in Holborn and a title that is the dc:title of
        that place"

 - English pubs ontology - work into pub listings?  Merge with ChefDan?

 - Machine-friendly routing around the site:

     RDF form of index ------------|
     RSS Recent Changes -----------|
                                   |---> RDF for each page
     HTML "link rel" for a page ---|

   Examples:
     RDF form of index:
       http://www.picdiary.com/pics.rdf
       http://un.earth.li/~kake/cgi-bin/wiki.cgi?action=index;format=rdf

     HTML "link rel":
       <link rel="alternate" type="application/rss+xml" title="RSS"
        href="http://www.picdiary.com/rss/highwalk.rss">;

      link tag lets you point from human-readable HTML into
      machine-readable alternatives

      RSS auto discovery - http://search.cpan.org/dist/HTML-RSSAutodiscovery/
      finds the machine readable version

 - example of the difference between object literals and object URIs

      <chefmoz:Neighborhood>Bloomsbury</chefmoz:Neighborhood>
        (this thing has a property called "Neighbourhood" whose value
         is the string "Bloomsbury")
      <chefmoz:Neighborhood
       rdf:resource="http://space.frot.org/a_space/Bloomsbury" />
        (this thing has a property called "Neighbourhood" whose value
         is the URI http://space.frot.org/a_space/Bloomsbury)

 - spacenamespace - we should link to URIs for
     - tube stations
         eg <space:Tube_Station
             rdf:resource="http://space.frot.org/a_space/Holborn_Station" />
     - pubs
         http://space.frot.org/a_space/George
     - neighbourhoods
         http://space.frot.org/a_space/Hackney

                  - and look at <space:contains> <space:pub>

 - look at the dmoz category RDF

 - could link OpenGuides in with photo albums eg YAPI
     "Show me all (x's) photos of Holborn"

-- 
grubstreet mailing list
http://london.openguides.org/old-list-archives/

• [grubstreet] Hackfest report Kate L Pugh 19:37 on 22 Apr 2003
  and the software seen in action at

Archive generated by mariachi 0.51.