[doap-interest] PloneSoftwareCenter and DOAP considerations

[Olivier Dameron]

On Mon, 12 Mar 2007 11:43:35 +0100, "Simone Deponti"
<shywolf9982 at gmail.com> wrote:

> That said, I still have to observe that the actual <Repository> model
> does not apply to my case and needs.

That I can understand :-)

> However, my proposal was to just maintain a general repository class,
> with inside it all the properties that are common between all
> classes, and, let's say "self complete". Which means, you don't know
> any extra information to know how to deal with it.

This seems like settling for the least common denominator... which
would bring about as much value as the 'classical' solutions and thus,
would suffer from the same limitations.

One of the nifty features of doap, is that it reliers on an RDFS (and
OWL also) specification, which allows to explicitely and formally
represent the semantics of what we are talking about. Not using it is
possible of course, but then we are also loosing the potential strength
of dedicated tools (you mentionned 'understand doap' previously in your
message, and this is exactly what is at stake here).

Now, what is great with RDFS and OWL is that they allow modularity. If
the core DOAP does not fit your needs, you are welcome to extend it by
providing specifications for your specific parts (here, it looks like
you would define one or several new subclasses of doap:Repository), and
then import both the core doap and your extension in your project
descriptions.
- Bonus1: your project description remains a valid RDF and doap
description, so it can be processed by standard tools just like a
description using the default doap specification. The new parts are
just ignored (at worst) or (at best) some basic inference can occur
(e.g. here for figuring out from
<Repository>
   <SomeFunkyRepository>
      <location rdf:resource="http://test.acme.com/test01/svn" />
   </SomeFunkyRepository>
<Repository>
that SomeFunkyRepository is a (unknown) type of repository
- Bonus2: instead of saying nothing about your URL, you provide some
information that would help making the distinction with anoter
unspecified URL
- Bonus3: the work you do will be reusable and expendable by others, so
we have an interactive increase of the overall quality... instead of
the stagnation in the swamps of the unspecified ;-)

See for example "Keeping modular and platform-independent software
up-to-date: benefits from the Semantic Web" from
http://protege.stanford.edu/conference/2005/schedule.html

Cheers,
Olivier