interfce to web services for scientific experiments?

[arya putra]

Hi Folks,
Very recently my Prof. gave me a new topic for implementation. The topic is "Defining an interface to Web Services for the description of Scientific experiments" . He hasnt explained me much about it but just that I have to make a generic interface so that any scietific experiment like Bio-Tubes, Telescope movements, bio-informatics experiments could easily be merged into my standard interface. Also it is generally abstract. My problem is I am new to web Services and I have no idea what he means by this.
I have just implemented Telescope movement on Web Services but I couldnt understand about this generic solution for any future scietific experiments.
Could we hold a discussion on this topic ? Please pur in your comments.Google wasnt of much help too.
Thanks.

[William Brogden]

That is certainly an interesting topic. I don't know if a general interface is possible, but it is worth a try.
I would say you should first concentrate on the use of XML for describing data. Once you get your XML document structure worked out, the web service end of things will be simple by comparison.
Generalizing an interface for something as open ended as "the description of Scientific Experiments" is going to require you to step back from immediate problems such as controlling a telescope.
I suggest that you should be looking into XML Topic Maps, and the Semantic Web.
Bill

[arya putra]

Hi Bill,
Thanks for both the websites. I have had a look at it. Now I am facing another challenge. I understand the concepts but I dont know where to start from, I mean there is no structured way that I am able to think about. Can you suggest what could be my possible starting point for making this INterface. I think its starting with DTD's. Is it?
Thanks.

[William Brogden]

Starting with DTDs? No! certainly not! You generate a DTD
after you have experimented with plenty of working examples and are sure you are on the right track.
It is hard to achieve the right level of abstraction when you are thinking about specific XML elements and DTDs. What you need to start with is what we used to call (in the environmental impact statement biz) the 10,000 foot view. For this, a large blackboard, whiteboard, or (large blank) sheet of paper is the starting point, not a computer screen.
OK - you are looking at the blank paper - imagine it encloses the entire world of "Scientific Experiments" - the world you want to describe - draw large blobs/lines/whatever that divide that world into categories that make sense to you. You may do this any number of times (new paper each time) with different aspects of the problem - subject matter, techniques, time-line development. Lots of paper will be thrown away - don't worry about it. Books/essays on the history of Science may be a help - also the sites I mentioned.
Hopefully after these exercises some pattens that make sense for organizing an XML document will emerge, and you can descend from the 10,000 foot view to start dealing with XML.
Bill

[arya putra]

Uffffff...I am already tensed, but am upto it. In the same context what do you think XSIL or XDF would be useful in this scenario. Both of them are used to represent the scientific datas or just writing the XML files would suffice.

[William Brogden]

I'm positive that many scientific disciplines have been thinking about this problem, but surely your professor doesn't expect one person to come up with a complete solution encompassing all previous work.
Bill

[arya putra]

Hello All once again,
Now am with some report and progress. I am concentrating basically on Astronomy and Seismic a�data and have XML file for both the cases. I have defined their structure based on my own knowledge of some sample data. Now my question is is this the Interface? Or what is it I am supposed to do next? Trust me guys am on my own, have no help and no guidance. Your replies would help me immensely. I am not getting any ideas. If somebody would like to have alook at the XML files then post reply I would put it across.
Thanks

[Balaji Loganathan]

Yes!.. Post your XML, I would like to see it.

[arya putra]

as asked here is the file. I have left the appendix part which is just value table for each constant.
thanks


<!ELEMENT ASTRO (DESCRIPTION?, DEFINITIONS?, INFO*, RESOURCE+) >
<!ATTLIST ASTRO
IDID#IMPLIED
>

<!ELEMENT RESOURCE (DEFINITIONS*, NAME?, TITLE?, DESCRIPTION?, INFO*,
FIELD*, TABLE*, LINK* ) >
<!ATTLIST RESOURCE
ID ID #IMPLIED
type(results|meta) "results" >

<!-- Details of the used parameters -->
<!ELEMENT INFO (#PCDATA)>
<!-- ID To refer this element
name Argument's canonical name (ASU);
when absent, the argument can't be used for back queries.
value Argument's contents
-->
<!ATTLIST INFO
ID ID #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED >

<!-- To specify ranges or lists of values
In case of use in <FIELD> tag, the type attribute
can be used to indicate the kind of values.
The multiple attribute specifies that it is
not an exclusive list of value, and in this case
the separator value indicates the character to
separate several values
type legal|actual
multiple yes|no
separator a letter, by default "," -->

<!-- Astronomical table -->
<!-- Note: table may be empty .. thus ================ FIELD* -->
<!ELEMENT TABLE (NAME?, TITLE?, DESCRIPTION?, COOSYS*, FIELD*, LINK*, DATA?) >
<!ATTLIST TABLE
ID ID #IMPLIED >

<!-- 1) In TABLE tag: Catalog or table shortname
ex: "GSC1.2"
2) In FIELD tag: field name
ex: "RA(J2000)" -->
<!ELEMENT NAME (#PCDATA) >

<!-- 1) In TABLE tag: Catalog or table description (paragraph)
ex: "This is an excerpt of the GSC1.2. This version was re-reduced
with PPM catalogue; see more details about..."
2) In FIELD tag: field description (paragraph) -->
<!ELEMENT DESCRIPTION (#PCDATA) >
<!ATTLIST DESCRIPTION
aboutCDATA#IMPLIED >

<!-- 1) In TABLE tag: Catalog or table title in one line
ex: "The HST Guide Star Catalog, Version 1.2 (Lasker+ 1996)"
2) In FIELD tag: field description (paragraph)
ex: "Right ascension in J2000, epoch of plate" -->
<!ELEMENT TITLE (#PCDATA) >

<!-- Definition of a field -->
<!ELEMENT FIELD (NAME?, TITLE?, DESCRIPTION?, VALUES*, LINK? ) >
<!-- ID To refer this element
unit Unit used for the field (see appendix)
datatype Datatype of field value
F-float, D-double, I-integer, A-ascii
L-boolean (logical), E-exponential
precision Precision of field value: number of significant digits
after the dot (ex: "3")
width number of characters "8"
format indicate the format by a "%fmt" template (as "printf()"
in language C). Use for coordinate format, time and date
formats (ex: "%RAh:%RAmd %DEd:%DEmd" - (see appendix)
ref Reference to the system for this field. For example it can be
a coordinate or a photometric system.
ex : #id("myJ2000") -> The syntax comes from Xpointers
name Alternative to specify the name of the field if it uses
only ascii characters (see the NAME element for the
other possibility)
ucd Unified column descriptor "POS_EQ_RA" (ESO/CDS work)
type To characterize the field
hidden for fields used typically for server/client exchange
no_query for fields which specify some parameters
(e.g. the equinox of a coordinate system)
trigger for fields which contain a parameter for an action

actualvalues Reference to the range or list of actual values
(it is an alternative to the <VALUES> entity in order to
be able to factorize them)
legalvalues Reference to the range or list of legal values
(it's an alternative to the <VALUES> entity in order to
be able to factorize them)
-->
<!ATTLIST FIELD
ID ID #IMPLIED
unit CDATA #IMPLIED
datatype (F|I|D|E|A|L) #IMPLIED
precision CDATA #IMPLIED
width CDATA #IMPLIED
format CDATA #IMPLIED
ref IDREF #IMPLIED
name CDATA #IMPLIED
ucd CDATA #IMPLIED
type (hidden|no_query|trigger) #IMPLIED >

<!-- To specify ranges or lists of values
In case of use in <FIELD> tag, the type attribute
can be used to indicate the kind of values.
The multiple attribute specifies that it is
not an exclusive list of value, and in this case
the separator value indicates the character to
separate several values
type legal|actual
multiple yes|no
separator a letter, by default "," -->
<!ELEMENT VALUES (MIN*, MAX*, OPTION*, NULL?) >
<!ATTLIST VALUES
ID ID #IMPLIED
multiple (yes |no) "no"
type (legal|actual) "legal" >

<!-- Min of a value range
value the min
inclusive yes|no (default: yes) -->
<!ELEMENT MIN (#PCDATA) >
<!ATTLIST MIN
value CDATA #REQUIRED
inclusive (yes |no) "yes" >

<!-- Max of a value range
value the max
inclusive yes|no (default: yes) -->
<!ELEMENT MAX (#PCDATA) >
<!ATTLIST MAX
value CDATA #REQUIRED
inclusive (yes |no) "yes" >

<!-- Item of list of values. The content of the
OPTION tag can be not empty to indicate
a corresponding sentence (ex: value="I/239"
and content: "Hipparcos catalog"
NOTE: OPTION may include VALUE for hierarchical menus.
(therefore OPTION can't have #PCDATA)
-->
<!ELEMENT OPTION (OPTION*) >
<!ATTLIST OPTION
nameCDATA #IMPLIED
value CDATA #REQUIRED >

<!-- Specify the value for the null representation
value the null representation -->
<!ELEMENT NULL (#PCDATA) >
<!ATTLIST NULL
value CDATA #REQUIRED >

[arya putra]

hello people !!!
could you kindly comment on my previous post ?
thanks for the support