This should copy an existing file into the knowledge base repo. The
functionality of this will vary depending on the type of file.
For the sake of simplicity, I will get it working for the following situations:
Markdown
If it is a markdown file it should be copied to the kb directory.
With Yaml title
If it has a yaml title, the file name should be changed to match it and a
warning displayed to the user so they know
Without a yaml title
The Name of the file should be converted to a title and used.
Both situations
In both situations, if a file already exists with the name of the "new" file, an
error is thrown and the user is asked to fix manually
Non-markdown
As time progresses, other plain text formats will probably be supported and will
be treated in a similar way to markdown
For binary files, there are 2 situations that I think are helpful:
An asset which is useful in another document
An example of this is an image that should be included in a markdown document.
These will be identified with the --asset flag. These will be stored within an
assets sub directory and will be indexed with the type of asset in the
database.
A binary document in itself
An example of this is a PDF that has been downloaded and should be treated as a
document in it's own right. These will be indexed as "normal" documents.
Both
In the case of binary documents, tags will be assigned by creating a yaml file
with the same name but with a yml extension. This will contain the same
information as the yaml header inside a markdown file.
For example, a document called test_document.pdf would have a yaml file
created with the name test_document.pdf.yml.
In the future, it would be helpful to have this auto-populate with information
although that is probably another issue.
This should copy an existing file into the knowledge base repo. The
functionality of this will vary depending on the type of file.
For the sake of simplicity, I will get it working for the following situations:
# Markdown
If it is a markdown file it should be copied to the kb directory.
## With Yaml title
If it has a yaml title, the file name should be changed to match it and a
warning displayed to the user so they know
## Without a yaml title
The Name of the file should be converted to a title and used.
## Both situations
In both situations, if a file already exists with the name of the "new" file, an
error is thrown and the user is asked to fix manually
# Non-markdown
As time progresses, other plain text formats will probably be supported and will
be treated in a similar way to markdown
For binary files, there are 2 situations that I think are helpful:
## An asset which is useful in another document
An example of this is an image that should be included in a markdown document.
These will be identified with the `--asset` flag. These will be stored within an
assets sub directory and will be indexed with the `type` of asset in the
database.
## A binary document in itself
An example of this is a PDF that has been downloaded and should be treated as a
document in it's own right. These will be indexed as "normal" documents.
## Both
In the case of binary documents, tags will be assigned by creating a yaml file
with the same name but with a yml extension. This will contain the same
information as the yaml header inside a markdown file.
For example, a document called `test_document.pdf` would have a yaml file
created with the name `test_document.pdf.yml`.
In the future, it would be helpful to have this auto-populate with information
although that is probably another issue.
This should copy an existing file into the knowledge base repo. The
functionality of this will vary depending on the type of file.
For the sake of simplicity, I will get it working for the following situations:
Markdown
If it is a markdown file it should be copied to the kb directory.
With Yaml title
If it has a yaml title, the file name should be changed to match it and a
warning displayed to the user so they know
Without a yaml title
The Name of the file should be converted to a title and used.
Both situations
In both situations, if a file already exists with the name of the "new" file, an
error is thrown and the user is asked to fix manually
Non-markdown
As time progresses, other plain text formats will probably be supported and will
be treated in a similar way to markdown
For binary files, there are 2 situations that I think are helpful:
An asset which is useful in another document
An example of this is an image that should be included in a markdown document.
These will be identified with the
--assetflag. These will be stored within anassets sub directory and will be indexed with the
typeof asset in thedatabase.
A binary document in itself
An example of this is a PDF that has been downloaded and should be treated as a
document in it's own right. These will be indexed as "normal" documents.
Both
In the case of binary documents, tags will be assigned by creating a yaml file
with the same name but with a yml extension. This will contain the same
information as the yaml header inside a markdown file.
For example, a document called
test_document.pdfwould have a yaml filecreated with the name
test_document.pdf.yml.In the future, it would be helpful to have this auto-populate with information
although that is probably another issue.