Prolog - Using terms to represent and access complex, nested data - data-structures

Question

my_computer([
case([
motherboard([board(plastic),ports(metal),slots(plastic),capacitors(plastic)]),
power_supply_unit([casing(metal),cables(plastic),connectors(plastic),capacitors(plastic),fan(plastic),transformer(metal)]),
central_processing_unit([board(plastic),fan(plastic),heatsink(metal)]),
random_access_memory([board(plastic)]),
graphics_processing_unit([board(plastic),ports(metal),capacitors(plastic),fan(plastic),heatsink(metal)])
]),
monitor([
lcd_screen(plastic),inverter(plastic),frame(plastic)
]),
keyboard([
key(plastic),frame(plastic),cable(plastic)
]),
mouse([
key(plastic),wheel(plastic),casing(plastic),cable(plastic)
])
]).
What should I do to in order to run questions like monitor(X). or motherboard(X) to give one or all layers of (sub)materials (Like my_computer(X). would do) ?
Would the code below be more useful for asking such questions? Question about one layer of submaterials is answered easily this way.
my_computer([case,monitor,keyboard,mouse]).
case([motherboard,power_supply_unit,central_processing_unit,random_access_memory,graphics_processing_unit]).
motherboard([board,ports,slots,capacitors]).
power_supply_unit([casing,cables,connectors,capacitors,fan,transformer]).
central_processing_unit([board,fan,heatsink]).
random_access_memory([board]).
graphics_processing_unit([board,ports,capacitors,fan,heatsink]).
monitor([lcd_screen,inverter,frame]).
keyboard(keys,frame,cable).
mouse([keys,wheel,casing,cable]).

Answer 1

The short answer to your questions would be:
monitor(X) :-
my_computer([_, monitor(X), _, _]).
And similarly for keyboard or mouse, etc. The motherboard would be a layer deeper:
motherboard(X) :-
my_computer([case([motherboard(X), _, _, _, _), _, _, _]).
These predicates of course assume a fixed structure. If you wanted it a bit more general, you could do a more elaborate "hunt" for the embedded functors (monitor, motherboard, etc).
Depending upon your broader application goals, it's not clear to me that this is the best representation of the data. Good enough for now, but context might want to take it in a different direction.
Here's another approach, thinking of the data as individual facts which imply a tree relationship. Basically just has relationships. Separate the "material" facts as material(Item, Type):
item(my_computer, case).
item(my_computer, monitor).
item(my_computer, keyboard).
item(my_computer, mouse).
item(case, motherboard).
item(case, power_supply_unit).
item(case, central_processing_unit).
item(case, random_access_memory).
item(case, graphics_processing_unit).
item(motherboard, board).
item(motherboard, ports).
item(motherboard, slots).
item(motherboard, capacitors).
item(power_supply_unit, casing).
item(power_supply_unit, cable).
item(power_supply_unit, connectors).
item(power_supply_unit, capacitors).
item(power_supply_unit, fan).
item(power_supply_unit, transformer).
item(central_processing_unit, board).
item(central_processing_unit, fan).
item(central_processing_unit, heatsink).
item(random_access_memory, board).
item(graphics_processing_unit, board).
item(graphics_processing_unit, ports).
item(graphics_processing_unit, capacitors).
item(graphics_processing_unit, fan).
item(graphics_processing_unit, heatsink).
item(monitor, lcd_screen).
item(monitor, inverter).
item(monitor, frame).
item(keyboard, key).
item(keyboard, frame).
item(keyboard, cable).
item(mouse, key).
item(mouse, wheel).
item(mouse, casing).
item(mouse, cable).
material(board, plastic).
material(slots, plastic).
material(capacitors, plastic).
material(ports, metal).
material(casing, metal).
material(cable, plastic).
material(connectors, plastic).
material(fan, plastic).
material(heatsink, metal).
material(lcd_screen, plastic).
material(inverter, plastic).
material(frame, plastic).
material(key, plastic).
material(cable, plastic).
Then you can define a predicate to generate the tree for whatever level you wish. Here's an example that does it in the form of terms (not lists):
structure(Item, Structure) :-
( item(Item, _)
-> findall(T, (item(Item, R), structure(R, T)), Rs),
Structure =.. [Item |Rs]
; Structure = Item
).
So then:
:- structure(case, S).
S = case(motherboard(board,ports,slots,capacitors),
power_supply_unit(casing,cable,connectors,capacitors,fan,transformer),
central_processing_unit(board,fan,heatsink),
random_access_memory(board),
graphics_processing_unit(board,ports,capacitors,fan,heatsink)
)
This could easily be changed to provide results in a list form instead. For example, here's a predicate that takes the above facts and gives the form you originally presented in your question:
structure(Item, Tree) :-
( item(Item, _)
-> findall(T, (item(Item, R), structure(R, T)), Rs),
Tree =.. [Item, Rs]
; material(Item, Material),
Tree =.. [Item, Material]
).
And the item becomes a trivial result for a where_used(Item, Parent) predicate:
where_used(Item, Parent) :-
item(Parent, Item).
Again, it all depends upon how you want to use and manage the data.

Answer 2

Edit:
For fun, I cobbled together a pair of rules that generalize arbitrary depth access to structures of the form name([attr_1([attr_1_1,...attr_1_n([...])]), ..., attr_N([...])); i.e., to data that is stored as a fact that has the same general form as your my_computer/1. You can use it, if you like. In any case, it's a nice little demonstration of Prolog's potent recipe of higher-order predicates + explicit evaluation + homoiconicity:
attribute(Thing, Path) :-
call(Thing, Attributes),
path_through_attributes(Path, Attributes).
path_through_attributes(Path, Attributes) :-
( Path = (Func -> NextPath), atom(Func)
->
Attr =.. [Func, NextAttributes],
member(Attr, Attributes),
path_through_attributes(NextPath, NextAttributes)
;
compound(Path),
member(Path, Attributes)
).
Supposing we have a fact like my_computer/1 (just as it appears in the first part of your question), the the predicate attribute/2 can be used to access any of its attributes, nested at any depth, like so:
?- attribute(my_computer, case(X)).
X = [motherboard([board(plastic), ports(metal), slots(plastic), capacitors(plastic)]), power_supply_unit([casing(metal), cables(plastic), connectors(plastic), capacitors(plastic), fan(plastic), transformer(...)]), central_processing_unit([board(plastic), fan(plastic), heatsink(metal)]), random_access_memory([board(plastic)]), graphics_processing_unit([board(plastic), ports(metal), capacitors(...)|...])]
?- attribute(my_computer, case -> power_supply_unit(X)).
X = [casing(metal), cables(plastic), connectors(plastic), capacitors(plastic), fan(plastic), transformer(metal)]
?- attribute(my_computer, case -> power_supply_unit -> transformer(X)).
X = metal
I chose the ->/2 operator for the accessor-path simply because it has a convenient associativity (i.e., right: (a -> (b -> c))) and it is sort of suggestive of "reaching into a series of nested terms". But it's probably not a great choice. If I were going to use this frequently, I'd come up with a good operator for the purpose and declare it with op/3.
Since all the terms in my_computer/1 are in a list, you could make a general access predicate using member:
computer_attribute(Attr) :-
my_computer(Attributes),
member(Attr, Attributes).
It can be used like so:
?- computer_attribute(monitor(X)).
X = [lcd_screen(plastic), inverter(plastic), frame(plastic)]
Of course, because monitor is nested in case, you'll need to have a more specific approach to access the former.
Depending on how elaborate the data gets, this might be a good use case for pairs, association lists, or records. (There is also the new SWI Prolog extension providing the dict compound, but I don't recommend it. I have found them to be more trouble then they are worth. But that might just be a shortcoming on my side.)
The indentation of your second block of code makes it look like there is a hierarchical relationship between the my_computer/1 fact and the others, but that is an illusion. Proper indentation makes clear that each is simply stated as an independent fact:
my_computer([case,monitor,keyboard,mouse]).
case([motherboard,power_supply_unit,central_processing_unit,random_access_memory,graphics_processing_unit]).
motherboard([board,ports,slots,capacitors]).
power_supply_unit([casing,cables,connectors,capacitors,fan,transformer]).
central_processing_unit([board,fan,heatsink]).
random_access_memory([board]).
graphics_processing_unit([board,ports,capacitors,fan,heatsink]).
monitor([lcd_screen,inverter,frame]).
keyboard(keys,frame,cable).
mouse([keys,wheel,casing,cable]).
As a result, this representation will only work if you only have one computer with the relevant parts in the given namespace. Otherwise, if you have a second computer, you won't be able to tell which call to mouse(X) is supposed to be associated with which computer. However, you could give each computer a name and then define the different attributes as relations between the computers name and a list of terms. Then your representation would like so:
computer(mine).
case(mine, [motherboard,power_supply_unit,central_processing_unit,random_access_memory,graphics_processing_unit]).
....
This code can be queried like so:
?- computer(Name), motherboard(Name, Specs).
Name = mine,
Specs = [board, ports, slots, capacitors].
(Once you have a firm grasp of Prolog, you might want to investigate Logtalk, which is an OOP extension for Prolog. I have never used it, but it sound fun.)

Answer 3

You can also define a bill of materials (BOM) using definite clause grammar rules (DCGs). For example:
my_computer -->
case, monitor, keyboard, mouse.
case -->
motherboard, power_supply_unit, central_processing_unit,
random_access_memory, graphics_processing_unit.
motherboard -->
[board], [ports], [slots], [capacitors].
power_supply_unit -->
[casing], [cables], [connectors], [capacitors], [fan], [transformer].
central_processing_unit -->
[board], [fan], [heatsink].
random_access_memory -->
[board].
graphics_processing_unit -->
[board], [ports], [capacitors], [fan], [heatsink].
monitor -->
[lcd_screen], [inverter], [frame].
keyboard -->
[keys], [frame], [cable].
mouse -->
[keys], [wheel], [casing], [cable].
Parts that have components, e.g. monitor, are represented as non-terminals. Parts that are not made of other parts, e.g. keys, are represented as terminals (i.e. between square brackets). The standard phrase/2 predicate can be used to get the bill of materials for a specific part. For example:
| ?- phrase(monitor, Parts).
Parts = [lcd_screen,inverter,frame]
yes
| ?- phrase(case, Parts).
Parts = [board,ports,slots,capacitors,casing,cables,connectors,capacitors,fan,transformer,board,fan,heatsink,board,board,ports,capacitors,fan,heatsink]
yes
If you need to represent detailed information about a specific part, e.g. that a fan have three different modes, which one with its own RPMs, you can interpret the part name (which is an atom) as either a Prolog module or a Logtalk object identifier. The module or object can then nicely hold the details about the part.