Hi Junjun, would it be difficult for you to re-configure this for Peter accordingly?
a On Wed, Sep 28, 2011 at 6:13 AM, peters <[email protected]>wrote: > Hi Arek, > Thank you for your offer of help. > Here are some examples, and if you can do something with them that would be > great:- > > EMAGE text expression annotation dataset has attribute "Atlas ontology ID > of tissue (text annotation) " ie the ID of the anatomy ontology component > that has been annotated, but users would like to know the component name, > component path, developmental stage > and so on for that ID. These attributes are in the dataset Anatomy > components (component details), where the common attribute is ID (timed > stages). > > From the datasets Anatomy components (component details), and Anatomy > components (including subcomponents), users would like to know if the > anatomy components they are interested in have gene expression annotated in > EMAGE. Details of the annotation (gene, strength, pattern etc) are in the > EMAGE text expression annotation dataset. As above, the common attribute is > the ontology ID. > > The EMAGE submission dataset contains data regarding an individual assay > submitted to EMAGE. However it does not have details of the detection > reagents (probes) used, these details are in the EMAGE experiment dataset. > Users would be interested in the probe details for EMAGE submissions that > they have found. There are several common attributes between these datasets > but the most obvious one would be the EMAGE ID. > In the other direction, users might search for probes in the EMAGE > experiment dataset and want to know more details about the EMAGE submission. > > > The EMAGE submission dataset does not have details of spatial expression > annotation, this is in the EMAGE spatial expression dataset. It is likely > that users would want to know if a submission they had found has spatial > expression annotated. > In the other direction, users looking for spatial expression might want to > know more details about the submission. The EMAGE ID would be the common > attribute again here. > > I hope that this makes sense but obviously let me know if you need more > information. > > Regards, > Peter. > > > On 27/09/2011 15:38, Arek Kasprzyk wrote: > > Hi Peter, > i did not make myself clear. I was not talking about bringing user defined > linking back in. I was more thinking along the lines that there are > typically certain datasets and that your users should like to link in order > to do their favourite multi-dataset queries. If you tell us what they are > we'll be able to preconfigure the interface such that these queries become > possible again without users being forced to do the GUI gymnastics as they > used to do in 0.7. > > We just need concrete examples of multi-datasets queries that your users > typically do and we could preconfigure them for you if it makes sense. > > As i mentioned in my previoius email, in the future you will be able to do > such things on the central portal yourself but this is ... in the future. > > For now we need an email from you with concrete examples so we can see if > we can help you and keep your users happy :) > > a > > > > > > On Tue, Sep 27, 2011 at 9:01 AM, Peter Stevenson < > [email protected]> wrote: > >> Hi Arek, >> I just meant linking in the v0.7 sense of using importables/exportables in >> order for the user to get attributes from separate datasets. I can give >> details of the importables/exportables I used if that's useful. However it >> sounds from the replies from Jonathan and Syed that its possibly not that >> straightforward to bring that type of configuration into a v0.8 model? >> Regards, >> Peter. >> >> >> On 09/26/11 19:14, Arek Kasprzyk wrote: >> >>> >>>> >>>> 2. User-definable linking is not currently implemented in 0.8. >>>>> >>>> This is a pity particularly for us because the EMAGE implementation >>>> relies >>>> on this feature quite heavily. >>>> >>>> >>>> Hi Peter, >>> it would be helpful if could suggest what type of linking you are after. >>> This can be pre-configured for you on BMC so your users would not be >>> affected. In the future we'll be able to do add your source yourself and >>> configure it in the Central Registry through our configuration tool >>> MConfigurator but for now you need to do via email :) >>> >>> a >>> >>> >>> >>> >>>> >>>> On 09/26/11 15:12, Jonathan Guberman wrote: >>>> >>>> Hello Peter, >>>>> >>>>> 1. EMAP anatomy ontology database is included: it is under the "Search >>>>> by >>>>> organism" tab, under vertebrates. >>>>> 2. User-definable linking is not currently implemented in 0.8. >>>>> 3. There is a problem with the 0.7 configuration that prevents these >>>>> filters and attributes from being imported into 0.8: in your >>>>> configuration >>>>> XML (available at http://biomart.emouseatlas.** >>>>> org/biomart/martservice?type=**configuration&dataset=**EXPRESSION_TEXT_TB< >>>>> http://biomart.emouseatlas.org/biomart/martservice?type=configuration&dataset=EXPRESSION_TEXT_TB>) >>>>> >>>>> >>>>> there is one MainTable/key pair listed at the top of the XML: >>>>> >>>>> <MainTable>EXPRESSION_TEXT_TB_**_EXPRESSION_TEXT_TB__main</**MainTable> >>>>> <Key>OID_109_key</Key> >>>>> >>>>> However, certain attributes and filters refer to other keys. E.g.: >>>>> <FilterDescription displayName="Experiment ID" displayType="text" >>>>> field="oid_108" hideDisplay="true"**internalName="oid_108_filter" >>>>> key="OID_108_key" legal_qualifiers="like" qualifier="like" >>>>> tableConstraint="main"/> >>>>> >>>>> And >>>>> >>>>> <AttributeDescription default="true" displayName="Emage ID" >>>>> field="accession_1037" >>>>> internalName="accession_1037"**key="OID_1037_key" >>>>> linkoutURL="http://www.**emouseatlas.org/emagewebapp/** >>>>> pages/emage_entry_page.jsf?id=**EMAGE:%s" >>>>> maxLength="20"tableConstraint=* >>>>> *"main"/> >>>>> >>>>> Since these filters and attributes refer to keys about which no >>>>> information is provided in the XML, they can not be recreated by 0.8 >>>>> and are >>>>> ignored. >>>>> >>>>> 4. and 5. BioMart 0.8 does not currently have these capabilities, but >>>>> they >>>>> are planned for future releases. >>>>> >>>>> Sincerely, >>>>> >>>>> Jonathan Guberman, PhD >>>>> Application Programmer >>>>> >>>>> Ontario Institute for Cancer Research >>>>> MaRS Centre, South Tower >>>>> 101 College Street, Suite 800 >>>>> Toronto, Ontario, Canada M5G 0A3 >>>>> >>>>> Tel: 647-260-7818 >>>>> Toll-free: 1-866-678-6427 >>>>> www.oicr.on.ca<http://www.**oicr.on.ca<http://www.oicr.on.ca>> >>>>> >>>>> >>>>> >>>>> On 2011-09-26, at 9:27 AM, Peter Stevenson wrote: >>>>> >>>>> I was looking at http://central.biomart.org/ after reading the recent >>>>> paper in Database. >>>>> It's nice work, looks good, and I'm obviously happy to see the EMAGE >>>>> biomart included in there. >>>>> However I have some quibbles about how the EMAGE interface has been >>>>> represented on there... >>>>> 1. The EMAP anatomy ontology database and its 2 datasets are not >>>>> included. >>>>> 2. There is no mechanism to do linked dataset queries. >>>>> 3. EMAGE text expression annotation dataset has several groups of >>>>> filters >>>>> and attributes missing. >>>>> 4. There are no default attributes pre-selected. >>>>> 5. There is no select all/deselect all in groups of attributes. >>>>> I don't know if some of these are technical limitations with >>>>> representing >>>>> a v0.7 implementation in >>>>> v0.8? I recognise some issues from when I tried to port to a previous >>>>> v0.8 >>>>> release candidate. Are >>>>> there changes at this end that I could make to help? >>>>> Regards, >>>>> Peter. >>>>> -- >>>>> >>>>> >>>> -- >> Peter Stevenson | [email protected] >> EMAP Computer Support | http://www.emouseatlas.org/emage >> MRC Human Genetics Unit | Phone: +44 (0)131 332 >> 2471<%2B44%20%280%29131%20332%202471> >> Edinburgh EH4 2XU. U.K. | >> > > >
_______________________________________________ Users mailing list [email protected] https://lists.biomart.org/mailman/listinfo/users
