On Fri, Mar 9, 2012 at 4:14 PM, Christian Weiske <cweiske@...> wrote:
> The PEAR installer uses, as most of you know, a REST interface to
> channel servers. It consists of several XML files at defined
> One of the XML files contains information about the package: Name,
> Description, License, Authors. It's at p/$package/info.xml, e.g. .
>  http://pear.php.net/manual/en/core.rest.php >  http://pear.php.net/rest/p/net_webfinger/info.xml >
> What I'm longing for is a way to discover information like the package
> home page URL, as well as the package's public code repository URL (as
> well as its code http interface URL).
> This information are very important for channel server aggregators that
> have been in the talk for a while.
> One aggregator is http://pyr.us/ written by Brett Bieber and used by
> Pyrus' "search" command to find packages across multiple channels.
> I'd like to give it a nicer web interface, and for that we need at
> least have a link to the package homepage.
> The question now is where to put that information. The DOAP
> project  already defines a schema to express such information, and
> we should re-use that. PEAR actually exports DOAP already, just add
> "/doap" to a package homepage.
>  https://github.com/edumbill/doap/wiki >  http://pear.php.net/package/Net_WebFinger/doap >
> The location of this information is the standing issue. I have several
> 1. Add another file to the REST interface, call it
> e.g. p/$package/doap.xml
> This means a new version (REST 1.5) of the PEAR channel server REST
> specs, but probably the least problems with existing client and
> channel server implementations. It might also be seen as cleaner.
> 2. Put that information into r/$package/info.xml in the DOAP namespace.
> This would mean we just have to adjust the XSD schema and are set.
> The tags would be optional. No new REST version needed.
> Only one counter argument comes to mind: The REST files were
> designed with bandwidth in mind, which means they are as small as
> possible (tag names like "c" or "n"). Adding DOAP information, that
> are unnecessary for most channel server clients, would mean a slight
> increase in bandwidth.
Not fussed about either approach or bandwidth implications. I'd probably go
for the incremental change (loosen xsd).
Am more interested in the different servers out there. I mean, we can send
in a pull request to Pirium and fix it in pearweb easily enough; but
there's a few other implementations around the place - some maintained,
As a different random thought, there's (also) things like
https://github.com/gkellogg/github-lod - so you can start at the github
repo and work backwards to generate the doap - which could be used to infer
project A owl:sameAs webpage B.