CGFCA info

[Alex-Darby04]

Data structures in the program:

TRIPLES:

Theres 3(?) arrays used for triples.

One 2D triples array stores the indexes for the concepts and relations.

A concept array stores the values for each of the concepts.

A relations array stores the values for each of the relations.

NumConcepts and number_of_relations stores the amount of concepts and relations the program has found respectively. This is the number used to index where the concept is stored in the concept array and the relations array.

Pos is just used to check if the concept or relation already exists. If it does it adds that index from concepts to the triples array rather than creating a new index. Same for relations

BINARIES:

Add binary does go through each pathway. It checks it by adding it to the path and checking if that target is also a source anywhere in the triples array. If it is, it calls add binary with that triple and then rinse repeat until your at a point where a target isnt also a source (an output concept).

Attribute keeps track of the original triple in the path.

Cycles are checked by seeing if the original triple’s source is the current triples target.

Context just makes the table that is built into the cxt file. It tracks repeats by checking it there is already a relation there.

Basically makes the table by running through each path and adding an X wherever there is a relation. Reports pathway if there is an input concept (root) and output concept (end node) in the same run through.

Breaks the loop if a repeat on the FCA table is found as that means you’ve visited that target from that triple already.

[Alex-Darby04]

Presentation - notes:

Hacky version: • Show off it working. • Almost 1-1 with the C++ code • Only works with CSV files as we didn’t see the need for CGIF • Bug with repeats not displaying in report – cxt file fine though

Excel add-in: • Show how it works. • Calls same program as hacky version, just uses the current csv file

New OOP version: • Recursion used, built to be more scalable • Being built to work with more file formats, currently accepts XML • Splits up the triples to binaries into multiple functions • Concept objects and Relations objects (triples)

Questions: • Elaborate on enable draw.io to write CGIF’s XML format for export to other CG tools • How important is having a UI or is a console okay for a majority of it?

Some notes from the meeting: Would be a good idea to save the positional data to create the FCL Remove circles for relations – just use arrows Would be good to have excel version auto-select data The draw.io should force the user to conform the conceptual graph syntax and inform the user when it tries differently. Graphical response when something fails syntax. (Possibly just remove features that shouldn’t be available?) Will have to write an extension for draw.io

[Alex-Darby04]

Plan for Sprint Week 2:

During the client meeting, we learned that the client was more interested in creating an efficient pipeline between draw.io and an output rather than having a multitude of different inputs that the program can use. Many of the inputs that were added to the project specification as respect to the standard formats that were being used. This doesn’t mean that the inputs aren’t an important part of the project, but they hold less priority than the direct integration with draw.io.

Here is a new MOSCOW for Sprint Week 2: Must have: • Direct integration with draw.io • A more linear pathway from draw.io to a final output • Using csv and XML file types • Have excel add-in use new CGFCA Should have: • Graphical response in draw.io when the graph breaks CG syntax rules • Excel plug-in auto-selects required data • Saves positional data to create the FCL/ do concept explorer • Have a GUI Could have: • Able to use multiple different file types • Able to still use CGIF/Old CG tools if needed