[base] MO terms (annotations) for experiments
Hi Working with the MageTab export I have noticed that it would be great to have additional properties for experiments that could hold MGED Ontology annotations, e.g. Experiment Design, Replicate Type, Quality Control Type. Up to now we've been using the Experiment Design and Experiment Type fields of experiments to hold this information, but it is a bit counterintuitive and does not restrict to available MO terms. In order to attach a fixed vocabulary term to an experiment it is probably easiest to make experiments annotatable and create one annotation type with selection of terms for every property. Further, the MO annotation types could be present in BASE by default (like the default protocol types), together with selections of MO terms. What do you think? Best wishes, Pawel PS The new MageTab plugin is already working in our BASE installation, and we are currently testing it with on a few experiments. I am planning to add support for pooling, and then it should be ready to release. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ The BASE general discussion mailing list basedb-users@lists.sourceforge.net unsubscribe: send a mail with subject unsubscribe to basedb-users-requ...@lists.sourceforge.net
[base] Project defaults in batch-import and experiment validator
Hello, I was wondering if the project defaults are used in batch importing, i.e. when a property is not specified in tab-delimited file but set as default in an active project? I did a quick test and it didn't work, so I thought I could suggest it. This way setting project properties upfront would save some work latter when editing the batch-import spreadsheets. I can imagine that in some cases it is not desired to set default properties automatically, so maybe a plugin configuration option to use project defaults would suffice. When updating with 'use defaults' option set, the plugin should overwrite existing properties. The second suggestion is also about the project default properties. We appreciate the nice and very useful links in the experiment overview/validator that help correct the experiment, and we saw a need for a new one(s). When an item is missing a protocol/software/hardware (or similar), the link could help in setting the default value in the active project. Or even suggest doing it for all the items of the same type having the property missing. This would be an awesome option allowing to fix the experiment quickly when one forgot to set the defaults in advance. Best regards, Pawel Sztromwasser -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ The BASE general discussion mailing list basedb-users@lists.sourceforge.net unsubscribe: send a mail with subject unsubscribe to basedb-users-requ...@lists.sourceforge.net
Re: [base] Project defaults in batch-import and experiment validator
More feedback:
I've extensively used the no column-use project default
functionality, and I think it's logical to do it that way, but the
expression-based enhancement sounds like a good next step forward.
On Tue, Oct 25, 2011 at 1:01 PM, Nicklas Nordborg nick...@thep.lu.se wrote:
On 2011-10-25 09:45, Pawel Sztromwasser wrote:
Hello,
I was wondering if the project defaults are used in batch importing,
i.e. when a property is not specified in tab-delimited file but set as
default in an active project? I did a quick test and it didn't work, so
I thought I could suggest it. This way setting project properties
upfront would save some work latter when editing the batch-import
spreadsheets.
I can imagine that in some cases it is not desired to set default
properties automatically, so maybe a plugin configuration option to use
project defaults would suffice. When updating with 'use defaults' option
set, the plugin should overwrite existing properties.
The batch importers doesn't really care about project default values.
It is handled entirely by the core code which has a contract to set
default values when creating new items, but only if no explicit value
has been set.
The key issue here is that if a column is mapped in the batch importers
an empty value is considered as an explicit request to set the value to
null, and the core will not use the default value. In other words, when
using the batch importers the project default values are only used for
unmapped columns.
There are also a lot of changes in this area in BASE 3. It is now for
example, possible to have more than one default value and the core tries
to match everything depending on the subtype of an item.
So, I don't really know what is the best solution here... Maybe, instead
of using hard column mappings (eg. \Protocol\) we could add support
for expressions. Something like =default() would always select the
project default value, or =defaultIfNull('Protocol') select the mapped
protocol if a value is specified, but uses the default if the column is
empty.
The second suggestion is also about the project default properties. We
appreciate the nice and very useful links in the experiment
overview/validator that help correct the experiment, and we saw a need
for a new one(s). When an item is missing a protocol/software/hardware
(or similar), the link could help in setting the default value in the
active project. Or even suggest doing it for all the items of the same
type having the property missing. This would be an awesome option
allowing to fix the experiment quickly when one forgot to set the
defaults in advance.
The fix it links can currently only provide a link that opens an edit
dialog. The user must do the change manually. Automatic fixes would
really nice and could probably be done for several other problems as
well. It is not straight-forward to implement since we'll probably have
to keep track of a lot more information related to each suggested fix.
Maybe we could define some kind of 'FixIt' interface and then use a
'FixItFactory' to provide actual implementations. Seems like something
for BASE 3.1 or later...
/Nicklas
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject unsubscribe to
basedb-users-requ...@lists.sourceforge.net
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject unsubscribe to
basedb-users-requ...@lists.sourceforge.net
Re: [base] Project defaults in batch-import and experiment validator
That I didn't know. So when no column mapping is provided for a
property, the project default is used (since the property is regarded as
not initialized, and not null). I also like the expression solution in
column mappings. It has an advantage over a plugin parameter because it
allows to select particular properties to apply default values to.
I like one-click fix-it buttons (one is available for inheriting
annotations if I am not mistaken), and they would definitely speed up
work with BASE removing some of the repetitive interactions. If it is
possible to include them in the roadmap for 3.1, that would be
excellent. The sooner the better:)
Pawel
On 25/10/11 16:17, Bob MacCallum wrote:
More feedback:
I've extensively used the no column-use project default
functionality, and I think it's logical to do it that way, but the
expression-based enhancement sounds like a good next step forward.
On Tue, Oct 25, 2011 at 1:01 PM, Nicklas Nordborgnick...@thep.lu.se wrote:
On 2011-10-25 09:45, Pawel Sztromwasser wrote:
Hello,
I was wondering if the project defaults are used in batch importing,
i.e. when a property is not specified in tab-delimited file but set as
default in an active project? I did a quick test and it didn't work, so
I thought I could suggest it. This way setting project properties
upfront would save some work latter when editing the batch-import
spreadsheets.
I can imagine that in some cases it is not desired to set default
properties automatically, so maybe a plugin configuration option to use
project defaults would suffice. When updating with 'use defaults' option
set, the plugin should overwrite existing properties.
The batch importers doesn't really care about project default values.
It is handled entirely by the core code which has a contract to set
default values when creating new items, but only if no explicit value
has been set.
The key issue here is that if a column is mapped in the batch importers
an empty value is considered as an explicit request to set the value to
null, and the core will not use the default value. In other words, when
using the batch importers the project default values are only used for
unmapped columns.
There are also a lot of changes in this area in BASE 3. It is now for
example, possible to have more than one default value and the core tries
to match everything depending on the subtype of an item.
So, I don't really know what is the best solution here... Maybe, instead
of using hard column mappings (eg. \Protocol\) we could add support
for expressions. Something like =default() would always select the
project default value, or =defaultIfNull('Protocol') select the mapped
protocol if a value is specified, but uses the default if the column is
empty.
The second suggestion is also about the project default properties. We
appreciate the nice and very useful links in the experiment
overview/validator that help correct the experiment, and we saw a need
for a new one(s). When an item is missing a protocol/software/hardware
(or similar), the link could help in setting the default value in the
active project. Or even suggest doing it for all the items of the same
type having the property missing. This would be an awesome option
allowing to fix the experiment quickly when one forgot to set the
defaults in advance.
The fix it links can currently only provide a link that opens an edit
dialog. The user must do the change manually. Automatic fixes would
really nice and could probably be done for several other problems as
well. It is not straight-forward to implement since we'll probably have
to keep track of a lot more information related to each suggested fix.
Maybe we could define some kind of 'FixIt' interface and then use a
'FixItFactory' to provide actual implementations. Seems like something
for BASE 3.1 or later...
/Nicklas
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject unsubscribe to
basedb-users-requ...@lists.sourceforge.net
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
The BASE general discussion mailing list
Re: [base] MO terms (annotations) for experiments
I see your point with changing ontologies. The reason I asked about making them predefined in the first place is that (for example) the export plugin could expect an annotation of certain name/id to exist in BASE, and could automatically pick it up for a user. No need to configure the plugin or its execution, so easier for a user and an admin. On the other hand, every BASE installation admin could make a plugin configuration, that would include the right, locally created annotation types to use. That makes the connection of the plugin to annotation type's name/id less tight, which is better from the design point of view. Pawel On 25/10/11 13:34, Bob MacCallum wrote: On Tue, Oct 25, 2011 at 12:16 PM, Nicklas Nordborgnick...@thep.lu.se wrote: On 2011-10-25 09:22, Pawel Sztromwasser wrote: Hi Working with the MageTab export I have noticed that it would be great to have additional properties for experiments that could hold MGED Ontology annotations, e.g. Experiment Design, Replicate Type, Quality Control Type. Up to now we've been using the Experiment Design and Experiment Type fields of experiments to hold this information, but it is a bit counterintuitive and does not restrict to available MO terms. In order to attach a fixed vocabulary term to an experiment it is probably easiest to make experiments annotatable and create one annotation type with selection of terms for every property. Further, the MO annotation types could be present in BASE by default (like the default protocol types), together with selections of MO terms. What do you think? I have also noticed that many of the experiment properties are annotation-like and that it would be better to simply use annotations instead. Unfortunately, it's too late to include this in the BASE 3 release, so I guess it will have to wait for BASE 3.1. Making the experiment annotable is fairly easy. The existing information must stay as it is. +1 for annotatable experiments Regarding default annotation types, I think it is best to not include any in a standard installation. Ontologies tend to change every now and then, so it's better to let administrators handle that. /Nicklas -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ The BASE general discussion mailing list basedb-users@lists.sourceforge.net unsubscribe: send a mail with subject unsubscribe to basedb-users-requ...@lists.sourceforge.net -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ The BASE general discussion mailing list basedb-users@lists.sourceforge.net unsubscribe: send a mail with subject unsubscribe to basedb-users-requ...@lists.sourceforge.net -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ The BASE general discussion mailing list basedb-users@lists.sourceforge.net unsubscribe: send a mail with subject unsubscribe to basedb-users-requ...@lists.sourceforge.net
