SDIWG:Action Items 20081219

From NAMIC Wiki
Revision as of 19:29, 16 January 2009 by Bkirschn (talk | contribs)
Jump to: navigation, search
Home < SDIWG:Action Items 20081219

Go back to top level of Resourcome working group discussion pages

Who: Natasha, Csongor, Ivo, Beth, Peter

Discussion and Action Items (2008-12-19):

  • What is minimum that is absolutely necessary? mechanism to publish: create form (auto-add to registry & email & widget for human-authentication)
    • Action: Natasha - weekly update of bioportal with latest biositemaps
    • Action: Ivo - weekly update of iTools already done
    • Action: Beth - document the fact that HTTP will inform last date/time of biositemaps file update (done)
    • Action: Beth - registration form for adding biositemaps to registry (done)
    • Action: Beth - Grep-like application against all biositemaps (Use Csongor's editor in browse only for presentation)
    • Action: Csongor - browseable mode for biositemaps editor
  • Do we have a good information model? Do we have good documentation?
    • Action: Someone (Natasha?) to email Joy at Stanford to review biositemap web site after above minimum requirements are met (e.g. here is where your current biositemap, how to view, update, etc.)
  • Note: Csongor back on January 8th
  • Note: Next meeting on 1-16-2008 (Beth to email reminder in January)

Outstanding action items:

  • Beth & Csongor: work on merging apis (complimentary functionality) upon his return from Australia (week of Dec. 15)
    • Csongor & I need to talk about this, but given all the editor work that is on Csongor's plate, I believe Michigan should be able to do this work
  • Csongor: Update Biositemaps Editor to allow invalid classes
    • Csongor, can this be done by end of January?
  • Beth & Peter: follow up with NCBC centers to publish & update biositemaps (note I2B2 & CCB use deprecated classes that need to be updated)
    • wait on this until other outstanding issues are completed
    • comment out deprecated classes for now (done)
  • Ivo: Update iTools application to consume new biositemaps RDF files via RDF-to-XML web service
    • Ivo/Natasha: Outstanding issues listed in followup email
  • There are problems with the database or bioportal that need to be resolved in order to expose NCBC resources on bioportal
    • Natasha: early January release should fix this
  • Beth: will clarify who will develop biositemaps search application following CTSA call regarding BRO/IM harmonizing
    • While we didn't get a chance to discuss this on the CTSA call, Michigan is willing to work on this with a target date early in 2009 (an exact date wouldn't be available until we can get our team to meet after the holidays).
  • Modify Biositemaps Editor to support multiple resource types
    • Csongor: to be done early next year (January 2009)
  • Modify Biositemaps Editor to support harmonized CTSA biositemaps information model:
    • Csongor: update editor
    • Question: Can Harpreet to write converter?
  • The expanded/harmonized biositemap has 25 possible properties which should be reviewed/trimmed down if possible
    • Byline will be dropped
    • Language and platform kept as optional
    • biositemap_author kept as optional (note that CTSA wants this not displayed in the editor -- they see it as a disincentive)
  • A significant outcome of the harmonizing call was the much broader definition of what is a Biomedical Resource that CTSA uses. Nancy and Harpreet were planning on following up with their proposed additions to the BRO first week of January

Biositemaps Web-Services Specifications

I. Biomedical Resource Ontology (BRO) ontology

  • ( The following methods/functions will be valuable:
    • getBRO(): returns an XML with the complete current BRO hierarchy (starts with BRO root node)
    • getParents(BRONode): returns an XML with the meta-data of all the parents (in the BRO hierarchy), given BRONode. Most of the time there will be 1 parent, but there may be many
    • getChildren(BRONode): returns an XML with the meta-data of all the children (in the BRO hierarchy), given BRONode
    • getPartialBRO(BRONode): returns an XML with the meta-data of the BRO sub-hierarchy starting with BRONode
    • getSiblings(BRONode): returns an XML with the meta-data of all the siblings (in the BRO hierarchy) of the given BRONode (same hierarchy level)

II. Information Model (IM)

  • The following methods/functions will be valuable:
    • getBiositemapsIM(): returns an XML with the meta-data of all the required/formal IM fields, their properties and descriptions. Like in:
    • getBiositemapsIM_Property(int): returns an XML with the property-name of the IM field index by "int".
    • getBiositemapsIM_Description(int): returns an XML with the description of the provided IM field index by "int"
    • getBiositemapsIM_Description(property): returns an XML with the description of the provided IM property-name
    • getBiositemapsIM_Optional(property): returns an XML with the triples (name, property, value) of all non-standard, optional and non-core IM fields.

III. General Biositemaps.RDF web-service that provide not only the standard/required/IM meta-data, but any project/center/field- specific meta-data provided by the Biositemap creator/curator

That is, we can have a center that has created a new Biositemap.RDF object, which contains the triple (name=NewField; property=NewProperty; value=NewValue). Suppose, "NewField" is *not* in the Biositemaps IM. We still need to provide services for people/ tools to retrieve this triple in XML, just like we allow retrieval of IM fields. This may be relatively easy, once we have the first two extensions (I. and II.).

iTools processing (consumption/production) of Biositemaps.RDF

  • Date: 01/14/09
  • Status of the current implementation of iTools Yahoo-WebSearch of Biositemaps.RDF
    • iTools WebSearch starts automatically every Friday morning. It may also be manually started by admins.
    • After the completion of the auto WebSearch, iTools starts is own custom designed Web-Crawler, which traverses the entire domain and extracts all Biositemap.RDF objects there.
    • Finally iTools combines both the Web-Search and the Web-Crawler results in the iTools SandBox. There are no identifiers indicating how was a Biositemaps.RDF object obtained (via web-search or web-crawling).
  • iTools uses its own parser to parse Biositemap.RDF documents. There are 2 reasons for not using the NCBO provided Biositemap.RDF web-service:
    • The Biositemaps.XML genereated by this service does not provide a valid Biositemap.XML result (it's incompatible with the (legacy) Biositemaps.xml schema/format).
    • The RDF --> XML web-service converter only rewrites the RDF tags, so one needs yet another follow-up parser applied to the resulting XML object. Thus, the iTools client uses its own parser to minimize the overhead.
  • All Biositemaps.RDF clients (machines or humans), including iTools, will need an IM parser web-service, as described above.

Important Note

Note that in the new Biositemaps.RDF IM there is no NCBC Center-name, which used to be a key tag in the old Biositemap.xml schema. This is now replaced by an Organization tag. As a result of that, iTools will not display NCBC-center-specific view in its tabular of graphical navigation panels.

BK: actually there is a center-name -- unfortunately the above IM is not alphabetically sorted, but the center property does exist along with organization.
ID: Yes, 'center' it is defined by IM, but if you see this example, not all the resources have this field. If all resources are not guaranteed to have a clearly delineated center information, iTools will not be able to properly place these in the tabular/hyperbolic views.