Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Science Technology

Moving Sensor Data Onto The Internet With SensorML 99

Posted by timothy from the we-know-how-you're-feeling dept.
Roland Piquepaille writes "According to this Sensors article, a new XML encoding scheme may make it possible for you to remotely discover, access, and use real-time data obtained directly from Web-resident sensors, instruments, and imaging devices. By describing sensors using SensorML, anyone can put sensors or sensor data online for others to find and use. And because it's XML-based, it means all this data will easily be searchable. "For example, searching for particular kinds of sensors and data in a particular geographic region, with data collected within a particular time window, will be easy. This has significance for science, environmental monitoring, transportation management, public safety, disaster management, utilities operations, industrial controls, facilities management, and many other activities." In this column, you'll find a summary of the Sensors' story which contains more technical details about the technology. And if you're really interested, please visit the SensorML homepage."
This discussion has been archived. No new comments can be posted.

Moving Sensor Data Onto The Internet With SensorML More

Moving Sensor Data Onto The Internet With SensorML

Comments Filter:

  • SensorML (Score:5, Funny)

    by Jason1729 ( 561790 ) on Thursday May 01, 2003 @03:21AM (#5851063)
    They didn't shorten it to SML because everyone will pronounce it smell. Then half their FAQ will have to explain that smell sensors don't exist yet.

    Jason
    ProfQuotes [profquotes.com]

  • Well, this makes for some interesting Flash Apps (Score:3, Interesting)

    by JasonKey ( 656223 ) on Thursday May 01, 2003 @03:22AM (#5851064) Homepage
    With Flash's native XML interfaces, looks like some fun with graphing coming up. Anyone have any examples of this in use yet?
    • I don't have any examples of this, but it also seems like the sort of thing that SVG was designed for from the start. You could use XSLT or something to make SVG. Too bad it doesn't have better browser support....
      • No kidding. Was really hoping to see more native support within Mozilla by now, but alas, it seems to be still relatively quiet on the SVG / Mozilla front.

        By the time they get around to it, I am afraid the XML generated content within Flash will overcome the in some ways.
        • There is a natice SVG for Mozilla project, and it has some degree of SVG support, but they don't seem to have support for Phoenix (Firebird, whatever). Since the Mozilla development roadmap says that Phoenix should become the big mozilla browser, you would think that they would be trying to get it to work with phoenix.

          BTW, has anybody managed to get plugin SVG to work with Phoenix?

  • An application (Score:4, Funny)

    by utopyr ( 621354 ) on Thursday May 01, 2003 @03:24AM (#5851067)
    <I>
    <have fallen="true">
    <can>
    <get up="false">
    </can>
    </I>

    • Re:An application (Score:2, Informative)

      by Anonymous Coward
      that should be:

      <I>
      <have fallen="true"/>
      <can>
      <get up="false"/>
      </can>
      </I>

  • trust (Score:5, Insightful)

    by kilf ( 135983 ) on Thursday May 01, 2003 @03:29AM (#5851075) Homepage
    It might be difficult to establish trust for these technologies. If I want to know the temperature in some distant city, how can I be sure that the sensor I address is correctly calibrated, or not resting near a air-con outlet? In fact, there would be no way to tell if the damn thing even exists- it could be a textfile sat on the sever or the local tourist office...

    • Re:trust (Score:2, Insightful)

      by SteveDob ( 449830 )
      Surely, unless you knew for certain that individual sensor results could be trusted, and possibly not even then, you would sample several devices in, or near, the location of interest.

    • Re:trust (Score:2, Informative)

      by Bertrum ( 631643 )
      And so you would use the data you get accordingly. The problems you foresee already exist for any kind of data gathering. Unless you do it yourself, you don't know how accurate it is (and even then you can delude yourself).

    • Re:trust (Score:3, Funny)

      by Anonymous Coward
      <sensor exists="true" iscalibrated="yeah">
      ...
      </sensor>

      • Re:trust (Score:1, Insightful)

        by Anonymous Coward
        Thank you, Mr. Anonymous Coward! You have shown us how easily XML solves yet another problem! The power of XML is truly amazing! Moreover, perhaps you can address the problems of people not bothering to fill all the fields correctly? And how do we know when the calibration was done, by whom, and how accurate it was?
      • <sensor exists="true" iscalibrated="yeah">

        I think you also need a youCanTrustMe="true" attribute.
    • This is the sort of thing that could be included in the XML format. If for instance you had a temperature sensor calibrated against a standard in a Telarc registered lab, the lab could provide along with the calibration certificate a digital certificate that could authenticate the sensor.

      Now that would be usefull.

  • Yes, Possibilities... (Score:5, Interesting)

    by Dracos ( 107777 ) on Thursday May 01, 2003 @03:52AM (#5851109)

    Just think of what could be done when Lego [lego.com] updates Mindstorms [lego.com] to use this.

    • Just think of what could be done when Lego [lego.com] updates Mindstorms [lego.com] to use this.

      Yes, I'm sure there are many many imaginative ways of encoding the three bits of sensor data that the Mindstorms RCX can recieve as XML

      000 001 010 011 100 101 110 111
      Those are all the possible states. Add tags to taste.

      • actually, each input is analog. I have muxed one of them before to get 8-bits of input. The RCX isn't bad, once you put J2ME on it, or something decent. Here is a page where someone did the same thing with 6 inputs: http://members.axion.net/~rduff/rcxinput.html
        • actually, each input is analog. I have muxed one of them before to get 8-bits of input. The RCX isn't bad, once you put J2ME on it, or something decent. Here is a page where someone did the same thing with 6 inputs: rcxinput.html [axion.net]

          Cool, thanks for putting me right. Electronics has always fascinated me. Pity I keep falling asleep right at the beginning when they explain what all the coloured bands on the resistors mean.

  • world.sensors.find("Osama") (Score:3, Funny)

    by Anonymous Coward on Thursday May 01, 2003 @05:30AM (#5851264)
    This will incredibly simplify work of many
    people:

    if sensor=world.sensor.find("Saddam"):
    print "Saddam is alive!"
    for msgtype in voice,sms,im:
    CIA.leavemessage(msgtype,"Saddam is at"+sensor.location)
    else:
    print "Saddam is dead!"
    CNN.call("Saddam is dead!")

    • Ah, yes. Just think of the applications!

      terrorists = world.sensor.find_by_attr("terrorist")
      terrorists = filter(terrorists, lambda t: t.country == 'USA'
      for terrorist in terrorists:
      CNN.call("%s might be a terrorists! Panic, and watch your most trusted news source!"%terrorist.name

  • What?! (Score:3, Funny)

    by Anonymous Coward on Thursday May 01, 2003 @05:30AM (#5851266)
    This is an outrage. What about the First Amendment? Our civil rights? I'm opposed to sensorship of any kind!

  • Why oh why XML? (Score:3, Interesting)

    by leandrod ( 17766 ) <l@@@dutras...org> on Thursday May 01, 2003 @05:45AM (#5851284) Homepage Journal

    Why XML with all its verboseness and hierarchy?

    What I want is a relational or SQL schema. Then a much slimmer data transfer format would be possible.

    Sure enough I can get XML data and input into a more useful SQL or relational database. But why go thru a verbose, hierarchical format, I can't see enough reason.

    • Surely it's obvious that adding angle brackets can turn any dull old sequence of name/value pairs into a powerful data warehouse?

    • Re:Why oh why XML? (Score:2, Insightful)

      by jon077 ( 638925 )
      Wait! Hold on, back up. HTML is XML, so it obviously is working for the majority of data transfers. Secondly, why would anyone give direct access to a DB? The slow connections of a DB are not suitable for presenting data to the public. I am sure many of the Web Services, extract the data, then cache it, or write it to disk, then present the same data to the world. Sure a better solution to XML may exist, but it is not reading directly from a DB. For now, Vive Le XML.

      • >

        HTML is XML, so it obviously is working for the majority of data transfers

        HTML is not data transfer, but presentation. XML is not a data format, but text markup. Different tools for different jobs.

        >

        why would anyone give direct access to a DB

        That is not what I called for. What I said is that instead of defining a hierarchical, verbose data format, we should have database schemas, possibly ANSI SQL ones if we can't get our act together around a really relational model. Then one can define


        • In short, you want us all to use the same database schema definition system, because then we can create a data exchange format that's more consise than XML, and get everyone to standardise on that. Sounds great. Let me know when everyone agrees and you've got it running. Until then I guess I'll have to stick with XML. XML is pretty good for a huge number of things. For any one of these things, something else is better. I'd rather have 1 pretty good thing than a huge number of better ones.

          I don't thin

          • >

            you want us all to use the same database schema definition system, because then we can create a data exchange format that's more consise than XML, and get everyone to standardise on that. Sounds great. Let me know when everyone agrees and you've got it running.

            The point is exactly that people don't know data enough. I want people to be educated; I can't bring this change about by myself. In this domain (sensors) I have no interest.

            >

            I'd rather have 1 pretty good thing than a huge number of be


            • I too want people to be educated, but I don't want to have to educate them. I use XML for APIs because I can tell people "send in some XML that looks like this example, and you'll get some back that looks like this example" and they say "OK". End of conversation.

              I use XML a bunch of other places too, and none of them are text markup or data storage. A relational model is great for data storage, but I can't say it's great for data interchange, because I don't even have a clear idea what that would mean.

              • >

                I can tell people "send in some XML that looks like this example, and you'll get some back that looks like this example" and they say "OK"

                I did the same think with simple, fixed-size fields sequential files.

                >

                relational model is great for data storage, but I can't say it's great for data interchange, because I don't even have a clear idea what that would mean.

                OK, let's step back and think; we're messing here.

                Obviously the relational model is for data storage, not interchange.

                And that you

                • "I did the same think with simple, fixed-size fields sequential files"

                  But in my case the fields aren't fixed size, not all the records have the same fields, etc. Flat files are just not as expressive as XML without specifying a bunch of parsing logic.

                  A simple COBOL file copy is just as good? So I can send it down the wire, not knowing what language, OS, or whatever the other end is using, and everyone will be able to use it?

                  Show me a format I can reasonably expect pretty much anyone to be able to parse

                  • >

                    in my case the fields aren't fixed size, not all the records have the same fields

                    The physical fields were fixed size, but you just made them as big as necessary... and you can do pretty much the same with field delimiters. Different tuple types are so simple too.

                    >

                    So I can send it down the wire, not knowing what language, OS, or whatever the other end is using

                    You specify an encoding, and agree on the schema. That's all that XML ends up doing for data exchange, anyway, but verbosely.

                    >

                    • "The physical fields were fixed size, but you just made them as big as necessary... and you can do pretty much the same with field delimiters. Different tuple types are so simple too."

                      Make them as big as necessary - that's not necessarily a finite value, so you're specifying some artificial limit on fields that could otherwise be as big as you want, and wasting all that space whenever the data is smaller. You can use field delimeters, and various sorts of tuples, but you have to specify all that markup, a
      • Wait! Hold on, back up. HTML is XML

        No, XHTML is XML. HTML is an application of SGML.

        http://www.w3.org/MarkUp/ [w3.org]

    • Re:Why oh why XML? (Score:2, Insightful)

      by Anonymous Coward
      XML has provided a set of rules for developing file formats. If you have ever had to sit down and think about how to make your information available to other people to use in their applications it's great. If you are dealing with semi-structured data like recipes [formatdata.com] it is ideal.

      Yes it is verbose and overkill for highly structured data but until someone develops/markets a method of developing file formats that are not verbose more suited to machine transfer its the best I am aware of.

      I do think we need this
      • I do think we need this extensible binary formatting language or what-ever it would be, but until then XML is allowing groups of people to agree on standard file/data formats a lot quicker and easier than starting from a blank piece of paper.

        OGC (Open GIS Consortium), an organization that was involved in the development of SensorML, has also developed a open straightforward binary representation for XML documents that features the direct, raw, binary representation of arrays of numbers that makes it well
    • Because there is a great variety of possible sensor types, and (at least curently) we can't imagine how to force all the necessary description into a table straightjacket. This kind of application really is ideal for a semi-structured language, which is what XML Schema enables.
      • >
        we can't imagine how to force all the necessary description into a table straightjacket

        It doesn need to be all in one table...

        • Correct. But if your multiple tables involves making choices as well as joins, then this is either equivalent to more than one Sensor language or you are on the path to inventing something with at least as much complexity as an XML-based solution. Discovery of the sensor that you want will require either joins or multi-DB queries.

          One goal of SensorML is to reduce the number of entry points. The cost of this is (of necessity) a flexible document structure. Hence XML.

          The SensorML discussed in the articl
  • Now THAT would be useful!

  • Feasibility of small implementations? (Score:5, Interesting)

    by dtmos ( 447842 ) on Thursday May 01, 2003 @06:01AM (#5851303)
    From perusing the SensorML site, SensorML seems geared for satellite-based geosensing and other applications for which significant computing resources are available. I'm interested in small wireless sensor networks, which have very limited computing resources (usually just an 8-bit 8051 or HC08-based MCU, running at 4 to 8 MHz, with about 5k ROM and 1k RAM available). SensorML seems to have a lot of optional fields that could perhaps be eliminated for a "stripped down" version suitable for these types of sensors but, while I'm not an expert in the field, it's always been my understanding that XML=bloat. Can anyone comment on the feasibility of SensorML for small embedded applications?
    • Unless your embedded devices run web servers it probably doesn't make sense. You would just have another computer reading raw data from the embedded devices and then publishing that as SensorML instead.

      -Kevin

      • You'd probably want that anyway. If all of a sudden, ten thousand people want to know the temperature in your backyard, an embedded CPU & webserver won't be able to keep up (slashdot effect on a micro scale). So it'd be better to have an n-tier sensor data reporting system that can scale as/when needed.

        Which is not to say that the Sensor ML spec would be *bad* for that -- just that there are other issues besides the communications protocol to worry about.

        Chip H.
    • I did something similar as part of an embedded systems project at uni, the simple sensors probably would never ever be doing complex xml processing, just spitting out the same response over and over with little changes e.g.

      Thermometer

      <sensor type="thermometer" scale="celcius" value="20"/>

      next reading might be

      <sensor type="thermometer" scale="celcius" value="25"/>

      the only bit that changes is the temp.

      No doubt an awkward format for really limited 'smart' sensors, but they're probably not the
    • There are decent ways around that verbosity- if you have a sensor net you want accessible, you're probably going through some manner of gateway already, which can be responsible for the XML encoding. There are XML compression schemes- I lost some of my links, but the one I was looking tended to get better compression on XML encoded data than normal compression on the un-encoded data, because it could rearrange and compress all of the metadata, as well as using the metadata to select optimal compressors for
  • ...was XML optimal for searchability?!

    • Re:Since when... (Score:2, Informative)

      by khuber ( 5664 )
      Since never. What about discovery? The article is full of XML hyperbole. The connection they didn't explain is that _if_ this stuff is tied into the SensorWeb, you could have those capabilities.

      This article should have really been about SensorWeb [nsw.gov.au] since SensorML is just an implementation detail.

      -Kevin

    • Re:Since when... (Score:3, Interesting)

      by jargon ( 75774 )
      And because it's XML-based, it means all this data will easily be searchable

      *boggle* XML doesn't exactly lend itself to searchability.

      I mean, there exists XML:DB [xmldb.org], but it is FAR from optimal for searching. Certainly not "easily searchable."

      Unless, of course, they are accustomed the the data being processed being unlabeled; then I guess some standard markup might be useful.
  • How about talkML

    this is useless nonsense to append brackets to
    everything

    It is just another layer of semantics

    it is too hot in here, I guess the
    temperature sensor
    is broken

  • Web Services Based LabView Next? (Score:5, Interesting)

    by AlabamaMike ( 657318 ) on Thursday May 01, 2003 @06:21AM (#5851331) Journal
    Seems to me that National Instruments could use this recommendation to develop a web services based version of LabView. It'd be cool to have a loosely coupled, geographically independant sensor network that one could run experiments against. Now if we only had RemoteHandsML.

  • Wow, lookit that! (Score:5, Funny)

    by mwood ( 25379 ) on Thursday May 01, 2003 @08:46AM (#5852002)
    They've invented...SNMP.
  • Bookmarking Article for Later, ignore.
  • A markup language for real-time monitoring of remote events... I can see it now...

    <ex-wife id=1>
    <screwing>
    milkman
    </screwing>
    </ex-wife>
    <ex-wife id=2>
    <screwing>
    that dickhead with the Trans-Am
    </screwing>
    <spending>
    most of my money
    </spending>
    </ex-wife>
  • It should be pretty easy to add a perl or python wrapper to DigiTemp [digitemp.com], I'll have to look into this when I get home tonight.

    bcl
  • Seems like this capability has already existed with java object serialization, this is usually much more compressed than xml and does not require the significant overhead XML has for parsing.

    MM

Slashdot Top Deals

Your password is pitifully obvious.

Close