Add Visual C++ as language?

[veitveit]

It is not a language by itself (C++ is) but it can be very helpful that a program was not implemented in pure C++

[magnuspalmblad]

Yes, I know .NET is not a language, but I used in the annotations as I thought it may be helpful to people developing in the .NET framework.

Do we want to add a field for "library" or "framework" to the annotations?

[matuskalas]

Re @magnuspalmblad ("Do we want to add a field for "library" or "framework" to the annotations?"):

Yes, I think that may be useful. A dependency (or a major dependency) in general. Could work as "free tags", with suggesting the registrants and curators the "tags" that have been used already.

However, when a dependency is a bioinformatics tool, it should sooner or later be properly registered in Bio.Tools and linked accordingly.

But I still think that execution platforms proper - including .NET - should perhaps rather be platforms (with Qt, Java, Python, X Windows, WWW, POSIX or Linux or so, etc...). Perhaps not implementations of the execution platforms, but "standards".

NB. This issue should be merged with #23.

[matuskalas]

Another thought: In addition to a "free tag", a dependency could also allow and support IDs/links such as Debian packages, Free Software Foundation's Directory entries, Wikipedia sites, or such...

[veitveit]

One could build a hierarchy built upon interfaceType, resourceType and language, making it more straightforward to choose only the options that make sense.

A "free tag" (if I understood that correctly) can help to let this hierarchy kind of autogenerate, by curators/registrants adding tags that they seem appropriate and missing.

2016-04-18 19:51 GMT+02:00 Matúš Kalaš notifications@github.com:

Another thought: In addition to a "free tag", a dependency could also allow and support IDs/links such as Debian packages, Free Software Foundation's Directory entries, Wikipedia sites, or such...

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/bio-tools/biotoolsxsd/issues/25#issuecomment-211500340

        \|||/
       (o o)

----ooO-(_)-Ooo----

Don't worry about life; you're not going to survive it anyway.

http://computproteomics.bmb.sdu.dk

[joncison]

I think that (hierarchy) could be interesting especially to help us define what we mean by the corresponding terms - also valuable if the bio.tools registration interface goes ahead and makes use of it (i.e. type-specific registration interface).

It'd be beyond the expressivity of XSD to encode it as constraints though (at least, in a simple schema)

[veitveit]

Actually, there is also the tag platform in bio.tools XSD. This is a bit confusing and calling it operation system is more appropriate.

About the hierarchy, wouldn't that be a nice addition to the Tool Annotator?

[joncison]

The Tool Annotators is mostly focused on EDAM annotation so it's out of scope BUT it will sit within a (revamped) registration interface - which could make use of such a hierarchy. Actually, this issue has come up before: https://github.com/bio-tools/biotoolsregistry/issues/54

[joncison]

Folks, for now (in the impending 1.5 release for msutils.org) I'm leaving frameworks and IDEs out; with bio.tools, we have to draw the line somewhere. Can always revisit this in 2.0

[magnuspalmblad]

Agree! It is best to focus on the tools that can easily be integrated in workflows and play well with other tools. Some of the GUI-based software can perform a wide range of operations, but may not necessarily produce output in some well-defined format. The "frameworks" that are code libraries are perhaps better described as "tools for making tools", rather than tools for analyzing mass spectrometry data.