Undirected Wiring Diagram Support

[bosonbaas]

Integrated the Undirected Wiring Diagram interface into AlgebraicRelations. This allows for:

• Defining SQL queries using @relation syntax
• Rendering SQL queries as undirected wiring diagrams

[jpfairbanks]

Should we refactor the Query type to be a C-Set extending the UWD C-Set type?

struct Query{WD}
  types::Dict{Symbol, Tuple{Array{String,1}, Array{T,1} where T}}
  tables::Dict{Symbol, Tuple{Array{String,1}, Array{String,1}}}
  wd::WD
  Query(types, tables, wd::WiringDiagram) = new{WiringDiagram}(types, tables, merge_junctions(wd))
  Query(types, tables, wd::UndirectedWiringDiagram) = new{UndirectedWiringDiagram}(types, tables, wd)
end

This already contains a UWD as a field, which is good, but I think with C-Sets we can do better. For example the RelationalPrograms module in Catlab defines the theory of typed relation diagrams which extend HypergraphDiagrams by having variable names on the junctions.

@present TheoryTypedRelationDiagram <: TheoryHypergraphDiagram begin
  Variable::Data
  variable::Attr(Junction,Variable)
end

HypergraphDiagrams already extend UWDs by having names on the boxes.

@present TheoryHypergraphDiagram <: TheoryTypedUWD begin
  Name::Data
  name::Attr(Box,Name)
end

which extend TheoryUWD

@present TheoryTypedUWD <: TheoryUWD begin
  Type::Data

  port_type::Attr(Port,Type)
  outer_port_type::Attr(OuterPort,Type)
  junction_type::Attr(Junction,Type)

  compose(junction, junction_type) == port_type
  compose(outer_junction, junction_type) == outer_port_type
end

Since the point of the other Query fields are to tie all the information back to the constraints of the schema, it makes sense to represent that information on the junctions and boxes in the UWD. For example the types should go on the junctions right, because those are the fields in the DB and the tables can go on the homs, because those are the relations. I think this would simplify the code a lot. This is the benefit of have no-cost datastructures. We can just make a new type of UWD that has these additional attributes and all the ACSet machinery will just make it work.

[jpfairbanks]

Addresses #6

[bosonbaas]

There are a few things that I can think of that need to be addressed before merging this, so I'll just be checking them off as I go! Feel free to add anything that should also be taken care of:

• [x] Updated README for new syntax
• [x] Make sure notebooks compile and are updated
• [x] Add more tests for new files

[bosonbaas]

An open question, should we keep the company_demo example workbook? It originally had value for presenting how relational queries are generated, but I'm realizing that it really doesn't fit into the "workflow" framework that we're pushing towards (something that the ml_demo workbook accomplishes).

[jpfairbanks]

It's a classic example, and I think that Workflows are just one way to create a Schema. We eventually need to implement a raw SQL to ACSet converter. I think we should keep that example

[bosonbaas]

I've finished all of the edits I can think of, I think that this PR is ready for a final review!

[bosonbaas]

I just realized that this is the wrong PR (an old branch which started dev for UWDs). The PR from the correct branch has been opened as #13.

[bosonbaas]

The functionality in this branch is included in the most recent PR with the version increase to v0.2.0.