Re: Getting descriptions for cgit

[Owen Taylor <otaylor redhat com>]

On Fri, 2009-03-20 at 14:41 -0400, Joe Shaw wrote:
> Hi,
> 
> On Fri, Mar 20, 2009 at 2:06 PM, Shaun McCance <shaunm gnome org> wrote:
> > I've long since given up on using RDF as a source format.
> 
> This may seem a nitpick, but your beef is with RDF-XML, which is just
> one way of representing the RDF data model.  There are other somewhat
> more readable formats, although none as readable as the INI-format,
> like N3 and Turtle.

I actually think that of the RDF representations, RDF-XML is the most
friendly to someone who doesn't know much about RDF but (like most
programmers) does have a reasonable understanding of XML syntax.

If I look at what Wouter came up with in:

http://mail.gnome.org/archives/desktop-devel-list/2008-January/msg00160.html

Sure it's beautiful and terse, but if you wanted me to modify it for
my project, I'd have (a small amount of) trouble, because I don't know
the quoting/escaping/ line-breaking/etc, rules of Turtle.

If someone gives you a skeleton for a RDF-XML DOAP file, you can just
pretend that it is a XML file format with a fixed structure and edit
accordingly (and using the XML support in your editor)

> Whether the DOAP tools, whatever they are, accept those other
> representations, I have no idea.
>
> > It's an interchange format.  Produce your data in a way
> > that's conducive to content producers.  Write tools to
> > massage that data into a format that's conducive to
> > interchange.  Win.
> 
> Agreed here.  It's a < 100 line Python script to transform the INI
> file into RDF-XML.  Who cares if it's reinventing the wheel if it
> makes people's lives easier in the long run.

Given templates GNOME contributors can handle inputting a small amount
of data in RDF-XML, in Turtle, in INI files,  in JSON, in s-exps, as a
Haskell program, or in any other way where the strings they have to edit
show up as strings when opened in a text editor.

It sounds like there is general agreement (of those paying attention
on this list anyways) that a generalization of MAINTAINERS checked into
modules is the way to go. So we just have to decide the details and go
for it.

- Owen