WirelessOntology

From W3C Wiki
Jump to: navigation, search

notes towards an OWL ontology for 802.11 wireless networking [1]

cf [2] - implementation of the ontology

Encapsulating a general system to express 802.11 parameters in RDF; look at [3] to see the ethereal interpretation of an 802.11 beacon frame.

[4] - a draft RDF graph representing the information in a 802.11 beacon frame.

[5] - the RDF/XML serialisation of the above graph; comments appreciated...

Also representing services/resources available over a wireless AP, status and uptime, and extending upwards to broader declarations about wireless 'communities'. PersonalTelco:CommunityDatabase is an attempt to represent much of this domain in an SQL schema, for [6]; this underlies much of the work on PersonalTelco:MoinMap

For community wireless networks we have...

  • A Node
    • A name
    • A location ( wgs84 lat/long, see GeoInfo )
    • Owned by someone, who could change
    • Admin'd by someone, who could change
    • Resources (zero or more, including any standard internet service (mp3 library, web site, etc), plus unique to [community] wireless networks:
      • Radio/connections, each radio or connection has...
        • Link layer (802.11a/b/g etc.)
        • ESSID
        • MAC Address ?
        • Network access/routing information
        • Status (Personal Telco has a good framework for this, see PersonalTelco:NodeStatus)...but we should consider status as having a date-time aspect as well...
        • Antenna info...coverage arc, antenna type, gain
        • Access limitations (WEP/etc)
        • encryption/authorisation/access? (WEP / IPsec / captive portal / other VPN)

let me see if I can get the hang of this, and inject a scheme that we've been basing our (swn) scheme on. nodes are defined as a collection of interfaces and services kept in an owner/location container. Here's an example of this using my node. --SeattleWireless:MattWestervelt

  • node location: 47.625477 / -122.324104
  • node name: NodeOne
  • node type: SeattleWireless:BxNode
  • node owner: MattWestervelt
    • contact info: mattw@seattlewireless.net
  • node maintainer: MattWestervelt
    • contact info: mattw@seattlewireless.net
  • Interface
  • Interface
  • Interface
  • Service
    • type: Internet Gateway (nocat)
    • details: Only available to 10.15.3.0/24 users, some ports restricted no configuration needed
  • Service
    • type: Internet Gateway (vpn/proxy)
    • details: Available throughout network, requires login/configuration
  • Service
  • Service
    • type: web server
    • details: OpenOffice mirror / Gutenburg mirror
  • Service
    • type: jabber server
    • details: provides local jabber connectivity
  • Service: game server
    • type: counterstrike

cf [7], [8], [9], [10], PersonalTelco:PersonalTelco, PersonalTelco:MoinMap, PersonalTelco:GeoWiki, PersonalTelco:CommunityDatabase, PostgreSQL Schema


As one who is interested in the history of technology and wants to be able to determine success criteria for evolving technologies, having seen the formally well specified but overcomplicated X.400 e-mail system fail and the amateurish but practical RFC822+SMTP system succeed, I wonder what the reason is for the high level of detail in this specification of a node database. Do any example scenarios or applications exist? Does anybody use this ontology for their own, practical daily use? What if the specified node has a lat/long or channel specification that is wrong or out of date? --Lars Aronsson, founder of the Elektrosmog Wi-Fi hobbyist group in Sweden, http://elektrosmog.nu/