docs: Initial documentation of CleverRDFLib #5

Looks good if a bit overwhelming at first. It might be useful to try and highlight better which should be my priorities to read, as a user. From what I see, that's probably "index", "basic usage", "class hierarchy", and "loading result". But even in "basic usage" it's got advanced stuff about registering custom handlers.

README.md

					
				@ -24,3 +30,3 @@

				python -m venv .venv

				source .venv/bin/activate

				pip install -e .[dev]

				pip install -e ."[tests,docs]

Is this right? Perhaps there's some subtlety I'm missing but the unbalanced quote looks highly suspicious

docs/class_hierarchy.md

					
				@ -0,0 +18,4 @@

				## Building the Hierarchy

				The class hierarchy is automatically built when you access it:

That's a clever way to defer the computation in cases where it might not be used. Is it likely that accessing it can take a long time then? I don't know how much effort the build is - but if that's likely to be very slow compared to a pure access operation, then maybe warn the user here.

docs/class_hierarchy.md

					
				@ -0,0 +166,4 @@

				### Datatype Properties

				Datatype properties link classes to datatypes:

Is "datatypes" a synonym for "built-in types" in this context? It's not especially clear what the allowed range of values is.

docs/loading_result.md

					
				@ -0,0 +366,4 @@

				### When to Use Which

				- **Use `is_successful_for_main_ontology`** (recommended): When you want to proceed if the main ontology loaded, even if some imports failed

				- **Use `is_successful_for_all_ontologies`**: When you require all ontologies (including all imports) to load successfully before proceeding

What would be the consequence of proceeding in the case where the main ontology loaded but imports failed? Alternatively, how do I know whether a failed import is likely to break something or can be safely ignored?

CI / lint (pull_request) Successful in 1m35s

Details

CI / typecheck (pull_request) Successful in 1m38s

Details

CI / behave (3.11) (pull_request) Successful in 1m48s

Details

CI / behave (3.12) (pull_request) Successful in 1m47s

Details

CI / behave (3.13) (pull_request) Successful in 1m43s

Details

CI / build (pull_request) Successful in 1m33s

Details

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin docs/initial_documentation-#2:docs/initial_documentation-#2

git switch docs/initial_documentation-#2

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master

git merge --no-ff docs/initial_documentation-#2

git switch docs/initial_documentation-#2

git rebase master

git switch master

git merge --ff-only docs/initial_documentation-#2

git switch docs/initial_documentation-#2

git rebase master

git switch master

git merge --no-ff docs/initial_documentation-#2

git switch master

git merge --squash docs/initial_documentation-#2