notes towards an OWL ontology for 802.11 wireless networking http://www.w3.org/TR/owl-ref/
cf http://downlode.org/rdf/wireless_networks/ - implementation of the ontology
Encapsulating a general system to express 802.11 parameters in RDF; look at
to see the ethereal interpretation of an 802.11 beacon frame.
- a draft RDF graph representing the information in a 802.11 beacon frame.
http://www.hackdiary.com/rdf/ap.rdf - 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'. CommunityDatabase is an attempt to represent much of this domain in an SQL schema, for http://personaltelco.net/; this underlies much of the work on 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 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)
- Radio/connections, each radio or connection has...
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. --MattWestervelt
- node location: 47.625477 / -122.324104
node name: NodeOne
node type: BxNode
node owner: MattWestervelt
contact info: mattw@seattlewireless.net
node maintainer: MattWestervelt
contact info: mattw@seattlewireless.net
- Interface
- type: client access
- layer 2: 802.11b
- essid seattlewireless-node1
- network: 10.15.3.1/24
antenna: SlottedWaveguide
- Interface
- type: upstream
- layer 2: 802.11b
- essid: southlink
- network 10.18.4.1/30
link: NodeFremont
antenna: HedgeTrimmerYagi
- Interface
- type: upstream
- layer2: 802.11b
- essid: swn-n1-8db
- network: 10.15.2.129/25
link: AwaitingLink
antenna: OmniDirectionalAntenna
- 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
- type: web server
details: NodeOneWiki provides network wide wiki
- Service
- type: web server
details: OpenOffice mirror / Gutenburg mirror
- Service
- type: jabber server
- details: provides local jabber connectivity
- Service: game server
- type: counterstrike
cf http://nocat.net, http://freenetworks.org, http://consume.net, http://seattlewireless.net, PersonalTelco, MoinMap, GeoWiki, 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/