The patch above does the step of including the vocabulary terms as predicates for Relations API. I still need to do another patch, probably to taxonomy_xml, to automatically expose them as RDF, and then expose something that makes it easy to output them in nice clean RDFa with the nodes. Once that is done, it seems pretty powerful to me. I like being able to write something and in a structured way say it was inspired by a book, that it implements a philosophy, or that it is useful for some specific goal.

This is partly done at bteaching.com now; the relations are visible to the user along with each node. They aren’t output in RDFa yet, though, that still needs to be done along with the automatic vocabulary exposure as RDF.

Anyway, I wanted to post what I have so far, as its in production on a live site and might be useful for someone else in its current form.

Note, Drupal is by no means the only or necessarily the best choice for site building. Choices abound: Wordpress for simplicity and elegance, CodeIgniter or Symphony for efficient PHP application coding, newcomers such as CubicWeb built on emerging semantic standards – google ‘choosing a CMS’ if looking for advice on selecting a system for a new site.

Suppose, however, that you have inherited a Drupal site or have chosen Drupal on its merits as a mature, open source platform with a thriving community of users and developers and a plethora of modules to perform nearly every conceivable web task. Then it behooves you to understand the Drupal Way of avoiding pain and achieving maintainability.

Interestingly enough, the “Drupal Way” is not authoritatively or precisely defined, yet one hears experienced Drupalers refer to it in those terms. Pro designer Roxy Caraway defines it as a set of “best practices to keep the community from getting too chaotic.” First and foremost, the Drupal Way means to use existing, community-supported modules in preference to custom coding wherever possible. When the core of Drupal is updated, it generally requires some work to make modules compatible with the new Drupal version. Using a well-supported module means that the module developer will do the work of adapting their module to the latest version of Drupal rather than whoever coded your custom module having to do that work specifically for your site.

In order to take advantage of the existing, supported modules that the Drupal community has to offer, another principle is to design your site at a high, general level. Although at some point you may want to show your developer screen shots of exactly how you want the site to look, start by outlining the general features you want the site to have. Caraway asks all nonprofits some basic questions such as “Are you going to have volunteers? Do you need people to sign up for events?” Features like that are already built into Drupal modules, so consider using what is available ‘out of the box’ if its behaviour is close to what you had in mind.

Matt Shepherd, lead Drupal developer at Illuminate ICT, explains “We sometimes find that customers over-specify their sites and cram them with functionality when all they maybe wanted was a simple site to advertise events and create news reports. When faced with a complexity which they’ve specified and has been built into their site, they feel threatened and less likely to maintain the site properly….A Drupal site spec has to take take into account the skill and experience of the owners of the site. It would be outrageous to specify a site that would require a high degree of competency to maintain when the people maintaining it aren’t able to (or don’t want to) progress beyond the basics – many of our customers are very happy using a word processor and sending email, but would be shy away from anything more complex.”

“A smart office admin could certainly maintain a well-build Drupal site, even with little prior experience, as long as they had a willingness to learn!”.

Caraway adds that “I think one of the things you really need to pay attention to, when you assign an admin to a Drupal site, they see sooo many options and most don’t even apply to the running of the site.

If you define permissions so that when your site admin logs in they see only what they need, that reduces the intimidation factor.

Ever site owner gets the top-tier admin login, but for day-to-day operations, usually the people maintaining it day to day are editing pages, adding pages, they’re not doing any configuration.”

Design and Theming
——————

Think Zen. Specifically, the Zen theme, or the Salamander – something minimalist and extensible, if you are going to create your own Drupal theme. Even if you choose to use a fully detailed available theme, try to choose one that uses good design principles in case you do need to edit bits of it later. Caraway provides a set of editable themes at http://catalog.designdabblers.com with images intended to be doctored by the themer.

The whole creative aspect of the site – the layout, artwork, fonts, how it will be laid on on the screen – this can be determined by the themer. Caraway points out, “For layout on a site, there are a lot of possibilities – you don’t necessarily have to have a blocky look and feel, you can do a lot of things different ways and achieve the same result with Drupal.”

Hosting and Maintenance
————————

Be careful when choosing a hosting provider. Make sure you have a host that either explicitly supports Drupal or provides access to your apache/PHP config files so that youcan provide enough memory to your drupal application. Drupal has been accused of slow performance on high-traffic sites, but proper tuning, memory allocation and server configuration (having memcache available) can make a big difference. For smaller or low-traffic sites, performance may not be a concern.

Training is another key to avoid external maintenance costs. Shepherd notes that “Training is a very important aspect of every site we create. Training your staff in at least the basics will ensure fewer support calls and a smoother entry in the Drupal system….A smart office admin could certainly maintain a well-build Drupal site, even with little prior experience, as long as they had a willingness to learn!”

The actual maintenance of a Drupal site may involve installing security upgrades through the administrative interface as they come out, as well as regular updates. This is why making sure custom development is performed in a maintainable way is so important. You will have to upgrade to maintain security, and you may want to in order to add functionality; and when you do, you don’t want your nifty custom code to break! Caraway explains that “Usually quarterly you just take your site offline, update your drupal code, run an update script, make sure its running, bring it back online. If people want to add in functionality that’s pretty standard, chances are there is community support for that.”

Cost
—–

The more standard you are willing to be, the lower your development costs will run. Caraway provided an actual pricelist, current as of beginning 2010:

basic drupal install: $500
brochure site: $550
directory: $650
blog/forum/enhanced dir: $800
community/social net/core media: $1200
eCommerce: varies
complex CMS (organizations, corporate sites, highly interactive): varies

While your mileage may vary, and custom requirements may quickly increase the price, a Drupal site does not have to eat your entire marketing budget.

Resources and Example Sites
—————————

http://drupal.org – THE Drupal site
http://drupal.org/project/Modules
http://drupal.org/project/Themes
http://drupalmodules.com – independent site with ratings and descriptions of available modules

Caraway’s Design Dabblers site: http://catalog.designdabblers.com
Illuminate : http://illuminateict.org.uk

Some sample nonprofit sites based on Drupal:
http://discuss.epluribusmedia.net
http://montanahope.org
http://ncasef.com
http://calvarygp.org

Author’s note – as an experienced Perl and PHP developer and who just recently entered the Drupal world, the ‘Drupal Way’ was a bit of a discovery for me, and thus this article.

From the README.txt that comes with the Relations API: ” Currently supports bidirectional node relationships based on the rdfs:seeAlso predicate. This could in the future fairly easily be extended to include support for user-defined predicates and for unidirectional relationships.” – so this was part of the possible future plans, at least.

Since most of the RDF work appears now to be focusing on Drupal 7, I’m hoping that arbitrary relations make it in there. What I would really like to see is the use of the taxonomy terms vocabulary that the RDF module auto-generates used as the predicate set – that would essentially reach the “en:anyword” goal mentioned below, and in a widely used CMS! Perhaps this will be possible by extending the Relations API. For now, using it in standard form at a teaching tips site, http://bteaching.com

Latest attempt involves Drupal 6 and the Relations API module, as it seems to me that Drupal 7 doesn’t yet have this particular functionality (though I am hoping it will by code freeze!)

Anyway, thus my latest discovery: the installation instructions in the INSTALL.txt packaged with Drupal 6.17 are WRONG. They tell you to make a copy of default.settings.php to settings.php before you visit the new site the first time and choose your language. This will result in annoying error messages like so: “Warning: Table ‘mydb.access’ doesn’t exist query: SELECT 1 FROM access WHERE type = ‘host’ AND …”.

Luckily the solution is documented here:
http://drupal.org/node/464982

but would it be too much to ask to correct the INSTALL.txt file for us old-fashioned text-doc-reading types?

We do have the rel= attribute, which we’re allowed to expand upon according to the spec:
http://www.w3.org/TR/html401/types.html#type-links

Since a source doc, target doc, and link tag comprise a triple, why not leverage this more by encouraging the use of vocabularies in the rel= attribute? It would seem to me to be the simplest possible solution and could be supported by many different tools.

rel= is indeed used within the RDFa spec, but I’d argue that by itself a link containing a rel= tag is sufficient to define a triple. I’d also like to see a commonly used curie of

en:anyword

to mean ‘anyword’ in the english language. Lets also leverage the existing structure of language – Google does!

My main server runs Fedora, which is supported but doesn’t have a packaged install. Going down the path of least resistance, I spun up a cheap Debian Lenny server at Rackspace.com and installed the nice debian packages following the instructions at http://www.cubicweb.org/doc/en/admin/setup.html. All went well until I hit the ‘Next’ link and got to the page Creation of your first instance. Oops! I haven’t installed a cube yet, and here it says “Now that we created a cube…”. Back, forth, nope – didn’t miss a step, must be a wrong link in the docs.

Backed up and found the tutorial with Steps for creating your cube. Continuing…

learning python-isms, such as the fact that classes must start with capital letters…

and YES! It works. http://173.203.29.23:8080/ Its password protected so you can’t see anything public yet, but I love the interface that encourages you to add relations to everything.

Drupal 6 detects my Mysql server without any problem…

(I was trying to install Drupal 7 for the RDF capabilities, it seems RDFCCK will be part of core in 7. But looks like may have to wait a few months.)

A bit of research determined that Drupal 7 requires the PDO extension to PHP. However, something funky in my Fedora OS setup didn’t let me recompile PHP from scratch, and yum update php wasn’t doing the trick. Finally, after looking at this page

http://www.electrictoolbox.com/update-php-command-line-yum/

I tried just yum installing the extensions, like so:

1010 yum install php-pdo
1011 yum install php-mysql
1012 yum update php
1013 yum install php-gd
1014 yum install php-xml
1015 yum install php-soap

and that worked. Your mileage may vary…

esw.w3.org/VocabularyMarket

esw.w3.org/SeedApplications

Evoc drupal module for importing RDF vocabs and exposing properties in Drupal
RDFCCK drupal module by the same author, Stephane “scor” Corlosquet
article by Marco Neumann on importing semantics into Drupal

Import SKOS into Drupal taxonomy but then do you need to use the RDFa module to have your Drupal content part of the linked data initiative?
————-
Follow-up (If I post as a comment, not visible from front page – need to configure WP to do follow-up threads better):

Reading Scor’s paper, sounds like work is heading in the right direction. The autocompletion sounds promising

“To this end, our module adds a new tab “Manage RDF mappings” to the content
type administration panel of CCK for managing such mappings cf. Fig. 2. An autocomplete list of suggested terms is shown, based on the keyword entered by the user.

The terms are coming from two different sources, which are detailed below.

External vocabulary importer service

The module RDF external vocabulary importer…”

866.897575000000057458

as an int, mysqlimport turned it into 866897575000000057458 – a bit off!

mysqlimport Ver 3.5 Distrib 5.0.45, for redhat-linux-gnu (x86_64)
(maybe this is fixed in 5.1, don’t know)