This is version 1 2 3 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Gadgets DB#

functionalities:#

• regroup information
• promote accurate information
• computer-friendly
• human friendly
• full text search
• precise queries
• describe interoperability features (plugs, protocols)
• improve extraction of information
• explain cryptic characteristics (e.g. Processor number gives gigahertz and nb of cores)

Sources of information:#

• online shops -> characteristics, price, images, text description, manual, link to manufacturer
• manufacturer website -> specs, whitepapers, manual,
• wikipedia
• gadget websites
• hacking websites -> internals, projects using the gadget
• search engine -> urls to check for more information

Modes of operation:#

• firefox extension that analyzes current page
• wiki like website
• mindmap
• match projects and gadgets (e.g. Project using ir on palm, suggest Zaurus)
• find gadgets that work together
• check source(s) for a fact
• add credibility to a fact

Important aspects of gadgets:#

• brand, reference, manufacturer
• price
• power supply, battery operation
• physical connectors
• displays
• speakers
• microphones
• keys, buttons
• touchable areas
• weight, size
• operating conditions (temperature)
• wireless communication
• processing units
• RAM
• ROM
• Flash
• expansion slots
• storage
• software compatibility
• availability (when, sellers)

Gather data from one web page:#

• need to use structure (tables for instance)
• customization per website
• level 0: gather key:value pairs , e.g. "Nb usb port" : "6"
• level 0: exclude parts of web pages that are about something else (menus etc)
• level 0: merge key:value pairs from multiple sources (keep traceability separately)
• level 0: store key:value pairs in repository
• level 0: consult key:value pairs
• level 0: find similar objects
• level 0: compare 2 objects (diff)
• level 0: search for objects with certain characteristics.
• level 1: associate keys with different names
• level 1: break up key value pairs that are grouped unduly by source
• level 1: add links automatically in consultation about key:value pairs (e.g. Processor reference, manufacturer etc.)
• level 1: add links automatically in webpage
• level: draw chonologies, charts
• level 2: look at unstructured doc and extract key:value information by matching keywords and patterns

Page observation data model#

A page observation can be described by:

• unique id of observation
• url: url where observation was made
• date time of observation
• title
• alias(es) of object described
• other key values pairs

This means that a page/observation is associated of aliases. This means a key can have multiple values. Not really ideal

Aliases can be stored in an index, occurrences of aliases in a document can be used to link to possible interpretations. A unique Alias can be added to a document (manually? Ouch!). An occurrence of an alias could be annotated with the unique alias (wiki syntax?)

Changing/adding values to an observation makes traceability harder. How do I avoid that? Maybe just keep an audit log.

One problem: how to go from observations to a single body of facts:

• create a group of all observations relating to the same item?
• merge/filter and create a new observation

Observations can be performed multiple times and yield different results (e.g. Price may change). Do we keep all individual observation or just keep track of changes?