[doap-interest] Changelog with DOAP
alex at passant.org
Thu Sep 14 16:18:48 UTC 2006
On 9/13/06, Olivier Dameron <olivier.dameron at univ-rennes1.fr> wrote:
> > but then it will be in RDF using a well-known vocabulary
> > so that you can SPARQL it, eg to get all changes from a maintainer
> > for a given timeline. Finally, the RDF file could be rendered to a
> > text changelog (with different formats) as I mention in my blog post.
> All the changelog stuff is still stored as plain text in one element,
> so from my point of view, even though you are using semantic web tools,
> you hardly exploit the "semantic" part. Still, it is a good idea to
> store everything in a single place.
> Also, what about using a rdfs:list to store the list of changes? One of
> the benefits is that you increase the granularity of you description so
> that each item of the list can be refered to by something else.
> Eventually, each item of the list could be either plain text or a mix
> of plain text and rdf ti increase the granularity of your description.
> This would allow you to retrieve all the changes relative to one
> subject. A first approximation of this retrieval could simply consist
> in getting all the list items refering to a particular subject. A
> semantically-enabled extension would require to have a model specifying
> if some subject is a sub-subject of another one, or is somehows related
> to it. Then, your semantic query would start from a subject, compute
> all the more specific ones and the related ones, and then retrieve all
> the relevant changes that were made. Is this what you had in mind?
Something like that, indeed :) Actually what I have in mind is to get
2 ways of represent the changelog for a given release:
- A simple text-description of the changelog, i.e. something like what
I have in my blog example. Even if that's not really powerfull from a
SemWeb point of view, it ould fist lead to changelog exports from a
- A list of changes for a given release (kind of rdfs:list or some
properties applied to a Changelog class). Each change could have
different properties as data, involved file, maintainer ... so that
it's more powerful for queries, and could also render GNU-style
changelog as mentionned before in this thread.
( One could argue that if we've got this granularity, we could avoid
the simple text desciption as it can be infered from this second one,
yet, some user might prefere just get a simple description (especially
for small projects, or if they don't use SVN)
So, it could lead to something like this:
- API updated to use both foaf:maker / sioc:has_creator
- Using object type in URL parameters
- Generating a basic FOAF profile to be used in user export
- French tranlation of the backend
- Adding doap.rdf
Thus, it will be more powerful for SPARQL or other queries about the
changes of a given project. Moreover, svn2changelog could be adapted
to produce RDF instead of plain text changelog.
What do you think of this ?
> doap-interest mailing list
> doap-interest at lists.gnomehack.com
More information about the doap-interest