rml:onLogicalSource instead of rml:logicalSource

[elsdvlee]

Agreement reached with the participant of the TF meeting on 10/1/2024. Broader agreement still needed.

[bjdmeest]

Property	Domain	Range
rml:onLogicalSource	rml:LogicalView	rml:LogicalSource

Otherwise you have the ambiguity of logicalSource having 2 domains: triplesmap or logicalView, or there's ambiguity between triplesmaps and logicalview definitions

[elsdvlee]

Notes of discussion TF meeting 7/02/2024: We keep the idea that we don't change the domain for the n rml:logicalSource property. Its domain remainsrml:TriplesMap and we introduce a new property to connect rml:LogicalSource to rml:LogicalView

This brings on to choosing one among the following properties (subject to easily understandable property name):

• onLogicalSource (might be confusing, might lead to errors because close to logicalSource)
• populatedBy
• viewOnLogicalSource

[pmaria]

a shorter alternative: rml:viewOn

[elsdvlee]

Other alternative: use the property rml:source and reconsider rml:LogicalView as a subclass of a rml:LogicalSource (issues #14)

• A rml:Source is, at its core, a resource on which a logical source can formulate a logical iteration using a reference formulation
• There are several types of rml:Source which are not explicitly defined, to keep things simple
• The properties with rdfs:domain rml:Source are to be considered properties of some undefined sub-class of rml:Sourceand as such are always optional, and may not make sense on a specific rml:Source
• Hence, an rml:LogicalSource could be a rml:Source for another rml:LogicalSource if a logical iteration can be formulated from it using the other logical source's reference formulation

(with thanks to Pano for the clear formulation of the above arguments)

[elsdvlee]

awaiting decision on https://github.com/kg-construct/rml-lv/issues/14 before we can fix and close.

[elsdvlee]

See https://github.com/kg-construct/rml-lv/issues/14: agreement to use rml:viewOn