Summary of Debian Science BOF at DebConf

[Christian Kastner]

Hi Andreas,

On 10/04/2010 08:40 AM, Andreas Tille wrote:
> On Sun, Oct 03, 2010 at 10:38:14PM +0200, Christian Kastner wrote:
>> I've been meaning to suggest new tags for a while now, but as I didn't
>> have anything to tag lately, it slipped my mind...
> 
> I'd consider your DebTags suggestion as an additional point which is
> missing on the Wiki page[1].  Would you consider adding it there for
> enabling a better decision process.

Will do. I'll start a draft tonight, and will flesh it out during the
week when I've done a bit more research.

>  IMHO, sequences of quotes in the
> mailing list are not that helpful.  (If  debtags-devel at l.a.d.o has
> better means for discussing DebTags I'd be happy to learn about this.)

I'd like to know, too.

>>   field::machinelearning:supervised
>>   field::machinelearning:unsupervised
>>   -- etc --
> 
> Could you please be a bit more verbose for people who are not experts in
> the Machine Learning field?  I'm not fully convinced here that we need
> extra facets - but this might just be me.  We currently have about 40
> packages in this task and it might be a critical mass for a more detailed
> specification, but I do not feel able to decide and I guess DebTaggers
> will feel similarly.

Yes, I was a bit brief there.

Taking a step back, the idea I proposed up there hinges on how facets
are treated, specifically if

  field::machine-learning::supervised IS A field::machine-learning

holds true. If that were the case, anybody looking for ML-packages could
look for field::machine-learning (which would return ~40 packages, as
you say) and then, for example, further filter for
field::machine-learning::supervised.

In other words, the functionality of a pure field::machine-learning is
preserved, while those who wish to tag their packages in greater detail
are able to do so. Everybody can go with whatever level of detail they
feel comfortable with.

Of course, the downsides are over-specification, and as you said, it's
only ~40 packages.

> In principle you
> are right that there is no objective reason to handle Biology
> differently than other sciences.  However, it should be clarified how to
> implement biology tags like
> 
>    biology::nuceleic-acids
>    biology::peptidic
>    biology::format:*

Off the top of my hat, biology::format:* should go into
works-with-format::*, and the other two maybe could be just moved to
fields::biology:.

This reminds me: with reference to the first two, I had a similar
problem in ML (don't remember where at the moment) -- I wanted to say
what kind of data is contained. Not the format, but the type of *content*.

I'm not sure, but it could be that the made-of:: facet was intendend for
this, though from the way it looks, it refers to formats, too.

>> As I said, there were other issues, but I'll have to research them a bit
>> more.
> 
> It would be great if you could take over this job (including propagating
> your suggestions to a Wiki which could be helpful in the design phase).
> If the DebTag design might in the end be more compatible to our tasks
> there might be better chances to map them and use DebTags more heavily
> in our Blends tasks.

Will do.

Christian