RE: SemWeb BOF @ ISMB 04

Hi Jim:

How does DFDL relate to the proposed Standard Hex Format

	 http://www.ietf.org/internet-drafts/draft-strombergson-shf-01.txt

which would also (I expect) allow binary data to be addressed using Xpath?

Cheers,

Tony


Tony Hammond

New Technology, Nature Publishing Group
4 Crinan Street, London N1 9XW, UK 

tel:+44-20-7843-4659
mailto:t.hammond@nature.com


====
Standards Track                                          J. Strombergson
Internet-Draft                                             InformAsic AB
Expires: December 28, 2004                                    L. Walleij
                                                          Ledasa Rangers
                                                            P. Faltstrom
                                                       Cisco Systems Inc
                                                           June 29, 2004


                        The Standard Hex Format
                     draft-strombergson-shf-01.txt
Abstract

   This document specifies the Standard Hex Format (SHF), a new,
   XML-based open format for describing hexadecimal data. SHF provides
   the ability to describe both small and large, simple and complex
   hexadecimal data dumps in an open, modern, transport and vendor
   neutral format.

====

> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org 
> [mailto:public-semweb-lifesci-request@w3.org] On Behalf Of 
> Myers, James D
> Sent: 27 July 2004 14:20
> To: public-semweb-lifesci@w3.org
> Subject: RE: SemWeb BOF @ ISMB 04
> 
> 
> 
> You might be interested in the Data Format Description 
> Language (DFDL) being standardized in the Global Grid Forum 
> (http://forge.gridforum.org/projects/dfdl-wg/). It is 
> essentially a way to describe ASCII or binary content in 
> terms of an XML schema, allowing you to reference data inside 
> binary files via Xpath, etc. (i.e. DFDL is meant to describe 
> existing formats rather than being a way to encode XML in 
> binary.) DFDL itself is still in flux, but there are a number 
> of efforts that have started in that direction including BinX 
> (www.edikt.org/binx/), and BFD 
> (http://collaboratory.emsl.pnl.gov/sam/bfd/). In the not too 
> distant future (months), I expect a DFDL 1.0 standard, 
> Java-based parser(s), and eventually web/grid data 
> virtualization services. If files have LSIDs, you have an 
> easy way to define LSIDs for structures inside and will be 
> able to use standard parsers to 'resolve' the data and 
> retrieve the desired sub-structure(s).
> 
>   Jim
> 
> James D. Myers
> Chief Scientist, Scientific Computing Environments Group 
> Computational Science and Mathematics Department Pacific 
> Northwest National Laboratory
> Phone: 610-355-0994
> Fax:     208-474-4616
> Jim.Myers@pnl.gov <mailto:Jim.Myers@pnl.gov> 
> 
> 
> > -----Original Message-----
> > From: public-semweb-lifesci-request@w3.org
> > [mailto:public-semweb-lifesci-request@w3.org] On Behalf Of wangxiao
> > Sent: Monday, July 26, 2004 11:49 PM
> > To: public-semweb-lifesci@w3.org
> > Subject: RE: SemWeb BOF @ ISMB 04
> > 
> > 
> > 
> > Greeting all:
> > 
> > I am glad to see this lifesci thread getting life now :-).
> > 
> > I believe one of the main problem in life science is the same
> > as the original problem that Eric Neumann has posted.  That 
> > is how to refer part of non-RDF document.  
> > 
> > I am working on a project aimed at using RDF to represent
> > 2D-Gel data.  I understood why Mr. Peter Murray-Rust did not 
> > accept Tim Berners-Lee's suggestion to create a CML ontology 
> > because I have the same concern of overhead for using either 
> > RDF or XML to represent Gel data as well.  In my cases, my 
> > concern is this.  For some applications, such as data 
> > submission and retrieval, I actually wanted the gel encoded 
> > in a "compact" form. Personally, I don't think XML is a good 
> > solution because there are more overhead than the actual 
> > payload.  Neither will RDF a good solution for the same 
> > reason.  It is not that difficult to create an arbitrary 
> > format to encode the gel data in a compact text based format 
> > but then I don't know how the URI should be assigned to each 
> > individual spot.  The URI for the spot is important because 
> > if a spot is IDed or used to perform MS.  The URI can make it 
> > easy to associate other type of descriptions. 
> > 
> > I guess this problem - assigning URI to part of another
> > resource -  is more general than it is just the life science 
> > alone. I would be very glad to hear if your "BDF" meeting can 
> > get some good solution.
> > 
> > By the way, I think RDF lacks a graphical modelling language
> > like UML.  One of the main RDF activities will be designing 
> > ontologies.  So, a graphical language sort of like UML will 
> > be very useful during the design phase and for the purpose of 
> > discussion and presentation.  I don't think UML is suitable 
> > to presenting RDF/OWL and I goggled internet but didn't find 
> > any useful one. I therefore created one.  It helps me and it 
> > might be of useful to you too.  An introduction of the 
> > language, which I called DLG2, is at 
> > http://bioinformatics.musc.edu/cc/tools/dlg2/
> > and a detailed 
> > documentation is at 
> > http://bioinformatics.musc.edu/cc/docs/dlg2/dl> g2.htm.  Please 
> > note, I just started writing these document. 
> >  There must be many problems.  Please forgive my careless 
> > writing and any suggestions and criticism are welcome!
> > 
> > Also, our project - Charleston Core
> > (http://bioinformatics.musc.edu/cc/) is > similar Eric Jain's 
> > but focuses on proteomic data.  If any of you have suggestion 
> > or want to collaborate, please feel free to contact me.
> > 
> > Xiaoshu Wang
> > 
> > 
> 



********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************

Received on Tuesday, 27 July 2004 09:38:20 UTC