Create DrasilConcept typeclass that directs to a chunk that defines the meaning of the instantiated class' name.

[balacij]

Contributes to #3314

I'm a little bit confused now by what DrasilConcept should be doing, and I think we need to clarify the terminology. This PR should most likely not be merged as-is.

Braindump

The 'Concept' typeclass provides information about the specific thing that an instance of a chunk (of type 'c') embodies. So, when I went to build DrasilConcept, I figured that it should point to the related ConceptChunk that explains what 'c' means (e.g., a ConceptChunk that defines what Theory Model means). And that's how I ended up with this implementation:

-- | What does this chunk type encode?
-- 
-- All chunk types in Drasil should instantiate this class.
class DrasilConcept c where
  -- | Provide the 'UID' to the 'ConceptChunk' that defines the concept type.
  metaConcept :: Getter c UID

Now three questions immediately arose:

1. Why point to another chunk?

1.1. Why to another chunk?

Well, that's just working on an assumption: that we want to capture "metadata" chunks as well, and keep them in close proximity to our "data" chunks, capturing information about their relationships.

1.2. Why only point?

Because the other chunk should exist already, and duplicating the type class fields with "meta" versions is unnecessary.

2. Why point to a ConceptChunk specifically?

In my head, this was just the most obvious thing to point to because we need to be able to point to something that defines our Drasil terminology, and using our current ChunkDB, we need to be able to resolve references to a single type. ConceptChunk is the most appropriate because it is the infimum of all chunks that instantiate Concept. But it might not be the right thing. As @JacquesCarette mentioned in #3314 (comment):

Concept is great because it defines things by "what information must be present" instead of by "a concrete representation".

So, an alternative design might look like the following, where it points towards another chunk that must have the necessary "conceptual" information:

-- | What does this chunk type encode?
-- 
-- All chunk types in Drasil should instantiate this class.
class Concept cd => DrasilConcept c cd where
  -- | Provide the 'UID' to a chunk (of type 'cd') that explains what 'c' is.
  metaConcept :: Getter c cd

Or, there could be yet another alternative version that recreates the 5 requirements of Concept (i.e., term, maybe abbreviation, concept domain, definition, UID) a bit more 'directly' (immediately returning the values), perhaps without the UID.

3. Hold on. Where do mandatory abbreviations fit in?

Recall: @JacquesCarette mentioned DrasilConcept in #3314 (comment):

What's implicit in the above is that we need to split DrasilConcept out from Concept, i.e. those concepts that we use for ourselves can have much higher requirements, such as making the abbreviation manditory.

The context is CI, which is essentially an IdeaDict (recall: vocabulary: noun + maybe abbreviation) with the requirement that the abbreviation must exist. Now, a CI could not fulfill the requirements of a Concept because it has no definition of the noun it declares.

3.1. Should CI also carry a definition?

If some concepts so common/required to have an abbreviation, shouldn't they also be required to have a (prose) definition as well?

Additional Notes

In the future, when we have typed UID references, the UID references should also be typed. This might be something good to consider in current design.

[balacij]

The alternative design mentioned in (2) has one pro over the existing code in the PR: we can have two instances for any chunk. For example, one that directs to a ConceptChunk and one that directs to a CI (assuming we add a definition to the CI type as well). The major con is that it's no longer giving a UID but an entire. With typed UID references, we can have

-- | What does this chunk type encode?
-- 
-- All chunk types in Drasil should instantiate this class.
class Concept cd => DrasilConcept c cd where
  -- | Provide the 'UID' to a chunk (of type 'cd') that explains what 'c' is.
  metaConcept :: Getter c (TUID cd)

[balacij]

Examples that might help us:

Theories:

-- | These are internal-to-Drasil common ideas, and need to be defined at the 
-- same time as theories.
dataDefn, genDefn, inModel, thModel :: CI
-- | Data definition.
dataDefn = commonIdeaWithDict "dataDefn" (cn' "data definition")    "DD"  [softEng]
-- | General definition.
genDefn  = commonIdeaWithDict "genDefn"  (cn' "general definition") "GD"  [softEng]
-- | Instance model.
inModel  = commonIdeaWithDict "inModel"  (cn' "instance model")     "IM"  [softEng]
-- | Theoretical model.
thModel  = commonIdeaWithDict "thModel"  (cn' "theoretical model")  "TM"  [softEng]

^ We would want to "point" to these.

What about the various "atoms" we have? For example, Expr, ModelKinds, or the prospective SystemKind. An instance of DrasilConcept would likely point to a ConceptChunk as well that defines the type names. But each one would be a sum type -- how should we capture the meta-information on those constructors as well?

[JacquesCarette]

Personally, I would be happy with

type DrasilConcept c = (Idea c, CommonIdea c, Definition c, ConceptDomain c) 

or even

type DrasilConcept c = (Concept c, CommonIdea c)

The data-structure we use is unimportant. The main thing that makes DrasilConcept different is that it must have all of the above information and how we use it. The second definition makes it clear how it differs from Concept.

DrasilConcept is much more a declaration of intent than anything else. It doesn't contain different information than a CI, it contains exactly the same information! So the difference is in declaring that this is information that will be used differently, rather than being different information.