spec: docs: logicalSource: add required charter reference formulations #152
Conversation
Broaded version of rml:RelativePathSource
| ## Access descriptions | ||
|
|
||
| RML-Core requires the `rml:PathFile` access description to be supported by any implementation to access files with an absolute or relative path. | ||
| This access description allows accessing files with relative and absolute paths from: | ||
|
|
||
| - `rml:CurrentWorkingDirectory`: relative to the current working directory of the RML processor. | ||
| - `rml:MappingDirectory`: relative to the location of the RML mapping. | ||
| - A string Literal: a string describing an absolute path against which relative paths are resolved, similar to the Base URI in [RFC3986](https://www.rfc-editor.org/rfc/rfc3986). | ||
|
|
||
| If `rml:root` is not specified, it defaults to `rml:CurrentWorkingDirectory`. | ||
|
|
||
| | Property | Domain | Range | | ||
| | ----------- | ------------------------- | ------------------------------------------------------------------ | | ||
| | `rml:root` | `rml:FilePath` | `rml:CurrentWorkingDirectory`, `rml:MappingDirectory` or `Literal` | | ||
| | `rml:path` | `rml:FilePath` | `Literal` | | ||
|
|
||
| Example of accessing a CSV file relative to the current working directory. | ||
| The file's absolute path is `$CURRENT_WORKING_DIR/file.csv` where `$CURRENT_WORKING_DIR` is | ||
| the location of the RML mapping. | ||
|
|
||
| <pre class="ex-source"> | ||
| <#RelativePathCWD> a rml:LogicalSource; | ||
| rml:source [ a rml:FilePath; | ||
| rml:root rml:CurrentWorkingDirectory; | ||
| rml:path "./file.csv"; | ||
| ]; | ||
| . | ||
| </pre> | ||
|
|
||
| Example of accessing a JSON file relative to the path of the mapping. | ||
| The file's absolute path is `$MAPPING_DIR/file.json` where `$MAPPING_DIR` is | ||
| the location of the RML mapping. | ||
|
|
||
| <pre class="ex-source"> | ||
| <#RelativePathMapping> a rml:LogicalSource; | ||
| rml:source [ a rml:FilePath; | ||
| rml:root rml:MappingDirectory; | ||
| rml:path "./file.json"; | ||
| ]; | ||
| rml:referenceFormulation rml:JSONPath; | ||
| rml:iterator "$"; | ||
| . | ||
| </pre> |
There was a problem hiding this comment.
I'm not convinced the access description should be in core.
I think it should stay in IO, since there is where we define access descriptions
Yes, it is used in core tests, but that is not a problem IMO. It is normal to have some core module that needs other modules before it can lead to something that works. And therefor it is also normal to include some of those dependencies to run tests.
In fact I would prefer for CSV and JSON to also be introduced in IO. I think it makes the specs more easy to follow. But since reference formulation is introduced in core I'm not as strongly opposed.
There was a problem hiding this comment.
It was discussed like this during the physical meeting to also move the access description, without it, you cannot perform any test cases nor have a stand-alone RML mapping if you only support Core. Therefore, the simplest access description (next gen of rml:source "/path/to/file.csv") is moved here. You mention you don't see this an issue, but having something standalone is IMO the best. Requiring people to implement some features of a module to have Core even working is not great IMO.
AFAIK, RML-Core would be the original RML actually where these things were included...
Charter requires CSV + JSONPath in Core, specs in IO registry for simplicity.
Related to kg-construct/rml-io#98