Part Description Language

This weekend was Business Time. How did we know it was Business Time? We both were wearing our Business Socks. We spent Business Time reconciling our large collection of mutually exclusive, contradictory, and just plain stupid ideas and features for Bricklet into one coherent grand unified theory.

The Bricklet project consists of a Part Description Language and a Part Sharing Framework. Here are some core concepts from the Part Description Language.

Parts vs. Devices:

• Parts are expected to be structurally composed with other parts

• Devices have well defined conceptual interfaces and might be comprised of parts or devices, but they don’t require structural connection

• Structural Interfaces define physical composition standards and are strongly typed (i.e. the BBa standard)

• Conceptual Interfaces informally describe device function. Practically they are unitless words. A fluorescent device might output Light, or Photons, or Fluorescence Units, etc. We will implement features like autocomplete to help users be as consistent as possible with these. (We expect to describe device interfaces more and more strictly as measurement standards are developed)

• Plasmids are supported as composite parts, comprised of modular plasmid elements like ori, amp, and ccdb (perhaps built with a different construction interface). Part instances are contained by plasmids (usually) and also have a physical location (well coordinates, freezer, lab, institution, etc.)

Bricklet’s first success, BBa:LOLPOP1

We hope that the loosely-typed description of a device’s input and output will sidestep (for now) the fact that there are basically no measurement standards for devices yet. This will allow people to identify conceptually what the input and output of a device is without having any idea how it could be measured - i.e. BBa:F2620 AHL -> PoPS. At a minimum this should enable bricklet to suggest device combinations and lists of functionally similar devices based on the stated interfaces.

An important takeaway is that conceptual interfaces are annotated as strictly as is useful, but aren’t expected to be unrealistically strict.

This enables great features, like the ability to accurately search parts based on function. For example:

• All visible reporters.
• All parts that take AHL as an input.
• All the parts that could interact with the one I’m looking at right now.

It also helps guide you when making functional relationships, as relating A to B means that the type of A’s output is compatible with the type of B’s input.

Since people will not spontaneously decide to use the same types (units) as everyone else, types can have relationships between them, too. For example, GFP is a fluorescent protein, which is something that produces light, which is more or less the same thing as photons or lumens. As such, when you search for light-emitting parts, the search results include parts that were described as producing GFP.