introduce provided source (#91) #95
Conversation
| | ------------------------| --------------------- | ---------- | | ||
| | `rml:sourceIdentifier` | `rml:ProvidedSource` | `Literal` | | ||
|
|
||
| The following example illustrates a provided source with its unique identifier `myByteStream`: |
There was a problem hiding this comment.
Don't we need a reference formulation? How does the processor know how to deal with that kind of ProvidedSource?
So an iterator + reference formulation?
I guess the actual dealing is then defined in rml-io-registry once we have an iterator + reference formulation.
There was a problem hiding this comment.
Ah good point. The idea is that the reference formulation can be any reference formulation supported by the RML processor. It is up to the mapping author to choose the correct one that will match the provided source at runtime. So this addition has no impact on that. I agree that this is not very clear from the text and the example. I will clarify.
There was a problem hiding this comment.
Yeah any formulation is fine, but we need to clarify that somehow that you probably need one and if not provided, we fallback to the default of a Logical Source.
There was a problem hiding this comment.
I'm not sure I follow. What is the "default [reference formulation] of a Logical Source"?
What I mean is:
say you have processed some data in some runtime process. The idea is to be able to provide that to an RML processor during that runtime. The type of data that is provided should match one of the reference formulations supported by the RML processor. The type of reference formulation for this specific source is determined, as per usual, by the rml:referenceFormulation of the Logical Source. All we need is to know which data matches which provided source in the mapping. That's why we need a rml:sourceIdentifier. This identifier will also be provided to the RML processor together with the source data programmatically.
So say you process that data to some structure on which the engine can execute JSONPath queries. Then a mapping could look like:
<> rml:logicalSource [
rml:source [
a rml:ProvidedSource ;
rml:sourceIdentifier "my-json-source" ;
] ;
rml:iterator "$" ;
rml:referenceFormulation rml:JSONPath ;
] ;
...There was a problem hiding this comment.
Yes! Looks what I have mind!
I'm not sure I follow. What is the "default [reference formulation] of a Logical Source"?
I was wrong, that's old RML. RML-Core now requires a reference formulation:
exactly one rml:referenceFormulation property
https://kg-construct.github.io/rml-core/spec/docs/#logicalSource
Old RML had a default 'tabular' for this to be compatible with R2RML.
| <#ProvidedSource> a rml:LogicalSource; | ||
| rml:source [ a rml:ProvidedSource; | ||
| rml:sourceIdentifier "myByteStream"; | ||
| ]; |
There was a problem hiding this comment.
Maybe add reference formulation here
| The following example illustrates a provided source with its unique identifier `myByteStream`: | ||
|
|
||
| <pre class="ex-source"> | ||
| <#ProvidedSource> a rml:LogicalSource; |
There was a problem hiding this comment.
The '#ProvidedSource' name I mean.
There was a problem hiding this comment.
BindingSource is suggested.
|
Example needed to specify what the inpout/output is that we expect. |
|
ProvidedTarget as well. |
resolves #91
TODO