Re: internal encoding guidelines, cheatsheets, and listings of TEI projects

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.

[1] http://dspace.org/introducing/dspace-video
[2] http://fedora-commons.org/presentations

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.

[3] 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?

Best,

   Piotr


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: [email protected]
> 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:
>>
>> http://wiki.tei-c.org/index.php/Category:Projects
>>
>> 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 (
>>> 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:
>>>
>>> https://listserv.brown.edu/archives/cgi-bin/wa?A2=TEI-L;ed2a925c.1003