Re: RDF tools for program versions

Date sent:      	Fri, 19 Nov 2004 16:52:32 -0500 (EST)
From:           	Charles McCathieNevile <charles@w3.org>
To:             	Danny Ayers <danny.ayers@gmail.com>
Copies to:      	John Fletcher <j.p.fletcher@aston.ac.uk>, www-rdf-interest@w3.org
Subject:        	Re: RDF tools for program versions

> On Fri, 19 Nov 2004, Danny Ayers wrote:
> 
> >> Are there any RDF tools which address one of my problems?  I
> >> make use of a number of software libraries which change versions
> >> from time to time.  Is there a vocabulary worked out which I could
> >> use to encode software name, version, what it depends on, etc. In
> >> theory each piece of software could come with an RDF file which
> >> described itself, how to install, etc.
> >
> >DOAP [1] is designed specifically for software projects, and covers
> >most of what you mention. I believe one exception is a term for
> >dependencies. As it happens I have one of those that needs licking
> >into shape, in a general-purpose project vocabulary [2] -
> >prj:dependsOn. In it's current form the schema probably isn't
> >consistent with the definitions in DOAP (or even with itself), but it
> >will be as soon as I have a minute ;-) Suggestions appreciated.
> 
> This is a reasonably common thing in several places - building an
> RDF-based desktop would be easier if you could specify these things.
> For testing your model, I suggest you have a look at a simple debian
> package - its dependencies need to include versions that are
> compatible for the dependency, etc.
> 
> (I have an ulterior motive - there is on and off talk of moving fink
> [1] to an XML format for its packaging, and I think and RDF/XML format
> offers some advantages for packaging information.)
> 
> cheers
> 
> Chaals
> 
> [1] http://fink.sourceforge.net
> 

Thank you for these suggestions.  DOAP certainly supplies a basis for information 
about software.  DOAP do say this (http://usefulinc.com/doap/goals):

"Specifically not in scope for the first iteration is the description of software 
releases. Work on this can be investigated as a follow-up initiative."

so they don't yet cover one of my objectives.

The general purpose project supplies another part of the framework.

Thanks again

John Fletcher

Received on Monday, 22 November 2004 10:22:18 UTC