Is allowing access only "project owners" to update the information
really a requirement? We've had an inventory of tools on the TEI wiki
for a long time, and I've never known of anyone vandalizing the record
of a tool they didn't create. A few of us filter requests for new
account on the wiki, which allow editing of any page. That seems to
work pretty well. If someone does vandalize a page, we can always roll
back the edits to an earlier version.
It would seen to me that a new inventory of projects could use similar
mechanisms which don't require that a username and password be passed
from one project owner to the next (this is, by the way, the sort of
information that is frequently lost in institutional memory). It
doesn't have to be a wiki per se, but it could simply be part of a new
TEI website in which editing privileges are widely distributed ... which
is exactly what the Board and I are moving towards in the TEI website
migration. I'll make a note to be sure to consider how to handle the
list of projects in phase II of the TEI website migration (once we get
through phase I).
On 11/5/16 11:13 PM, Piotr Bański wrote:
> Hi Lou and All,
> I would suggest using an existing solution. I've looked at DSpace and
> Fedora with the thought of kludging them from being
> digital-object-oriented to being metadata-oriented with digital objects
> possibly dangling from some listings. But they are far too powerful for
> the purpose and really different in focus from what we would need.
>  http://dspace.org/introducing/dspace-video
>  http://fedora-commons.org/presentations
> Metadata with optionally dangling objects... sounds like Zotero.
> Which also authenticates users and allows some access restrictions. But
> using Zotero for projects would be a kludge again. Still, this narrows
> the options a bit.
>  https://www.zotero.org/groups/tei
> Maybe someone knows of a Zotero-like off-the-shelf solution that could
> be used for maintaining a list of projects, with named links (for those
> ODDs and guidelines) and supporting tags that could make browsing the
> list easier and more fruitful?
> On 04/11/16 08:01, Lou Burnard wrote:
>> So clearly the way to address all of Piotr's concerns would be to
>> develop some kind of online database which could be easily updated,
>> searched, reported on etc. As was indeed originally intended for the
>> projects web page. The sticking point back in the nineties was finding a
>> low cost unfussy authentication mechanism so that only project owmers
>> could update their pages. Are we still stuck at that point? Surely
>> things like the existbased tei publisher are well up to the required
>> Sent from my Honor Mobile
>> -------- Original Message --------
>> Subject: Re: internal encoding guidelines, cheatsheets, and listings of
>> TEI projects
>> From: Piotr Bański
>> To: [log in to unmask]
>> Let me try a tiny bit of analysis.
>> Web page:
>> * hopelessly static in display (forms, no way to cross-search, see
>> facets, tag clouds or the like)
>> * hopelessly static in terms of content (updateable by mailing the
>> * hopelessly flat structure (well it's a list)
>> * there is a nice submission form
>> ** with some restrictions on e.g. the subject field (which imposes some
>> cross-classification, even though we can't sadly grab at it when
>> requesting the data)
>> * date of the last modification recorded explicitly
>> * update by e-mail (=nvolving a third party, subject to their time
>> * I don't think wiki is the proper medium for this, because it is also
>> static in terms of presentation. Not as hopelessly as the web page, but
>> * Data submission is arguably potentially more messy (no hard
>> restrictions) and arguably slightly more difficult (you have to request
>> a wiki account)
>> * the category system can be used for various cross-classifications but
>> it's unconstrained, and it still involves clicking a lot and waiting for
>> the new page to open.
>> * date of the last modification (and its nature! whether it was a typo
>> fix or content change) available within two clicks (from the history and
>> * direct and dynamic update of the information is a snap, reverting bad
>> edits is a snap as well
>> Half-measures that could be taken:
>> * One could imagine automated conversion from the current web page to
>> the wiki, connected with the setting up of an underlying categorization
>> (trivial, because they can be part of the direct output of the
>> conversion process).
>> * Update would be easier (because anyone logged could perform it).
>> * Display would still be static, although slightly more friendly
>> * Data input could be a mess. Ideally, the existing form could be used
>> for it, with a script converting the data into a wiki article that the
>> submitter could then paste into a new wiki page (or... send it to the
>> list, sigh)
>> * a little advantage in all this could be a potential increase in the
>> number of users of the wiki, which can translate into an enhancement of
>> its overall informational value
>> Project lists are good PR and can be helpful for users interested in
>> re-using the experience of others. I think the TEI has outgrown the
>> stage where such lists are necessary to legitimize a project. They are
>> still useful for users, though. Wiki is a half measure, but overall it
>> may improve access to this information and improve its content.
>> The above was a quick job that presents a subjective view.
>> On 03/11/16 20:32, Kevin Hawkins wrote:
>>> ... but I now see that earlier today, Serge Heiden helpfully created a
>>> category and template for projects for the TEI wiki:
>>> May this serve as the beginning of a revamped inventory of TEI projects,
>>> perhaps even replacing the one on the TEI website!
>>> On 11/3/16 2:15 PM, Kevin Hawkins wrote:
>>>> On the topic of moving the list of TEI projects (
>>>> http://www.tei-c.org/Activities/Projects/ ) into the wiki, those of us
>>>> who have administered the website and wiki have discussed this idea on
>>>> and off over the years. My response to why I've put putting it off is
>>>> essentially the same as what I wrote in 2010: