Hi Lou and All,

I would suggest using an existing solution. I've looked at DSpace[1] and 
Fedora[2] 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.


Metadata with optionally dangling objects... sounds like Zotero[3]. 
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.


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 task?
> 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]
> CC:
> 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
> webmaster)
> * 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 (= involving a third party, subject to their time
> constraints)
> Wiki:
> * 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
> still.
> * 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
> diffs)
> * 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
> (cross-classified)
> * 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.
> Best,
>    Piotr
> 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!
>> Kevin
>> On 11/3/16 2:15 PM, Kevin Hawkins wrote:
>>> On the topic of moving the list of TEI 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: