Closed pmaria closed 2 months ago
I sort of like 1, in the sense that it is semantically useful to know that a thing has a reference formulation and an iterator and is thus "logically iterable". rml:LogicallyIterable
could be defined in core and be the connection point for the logical source and the logical view specs.
@andimou @DylanVanAssche @anaigmo @elsdvlee interested to hear your POV.
In R2RML I find following classes; | Class | Represents | Minimum conditions |
---|---|---|---|
rr:LogicalTable | logical table | Being one of its subclasses, rr:BaseTableOrView or rr:R2RMLView | |
rr:BaseTableOrView | SQL base table or view | Having an rr:tableName property | |
rr:R2RMLView | R2RML view | Having an rr:sqlQuery property |
And following property: | Property | Represents | Context | Cardinality |
---|---|---|---|---|
rr:logicalTable | logical table | triples map | 1 |
Therefore, I prefer option 1, following more or less the same structure.
It would then be clearer to have rml:logicallyIterable
as property for the connection to the triples map, instead of rml:logicalSource
.
if I look at the R2RML spec, the view is a subclass of the logical table:
:R2RMLView rdf:type owl:Class ; rdfs:subClassOf :LogicalTable .
which could guide us to take the view as subclass of a logical source.
But there is also this concept of :BaseTableOrView
. Then what we could derive of this is that we can also introduce such a high level concept as e.g., a :BaseLogicalSourceOrLogicalView
. that's along the lines of 1 that @pmaria proposes but with a different wording.
I understood the alignment between the R2RML structure and the proposed RML structure as follows:
rr:LogicalTable
> rml:LogicallyIterable
rr:BaseTableOrView
> rml:LogicalSource
rr:R2RMLView
> rml:LogicalView
If the top classe should be named rml:LogicalSource
, then I would suggest to have as subclasses rml:BaseLogicalSource
and rml:LogicalView
, with rml:BaseLogicalSource
being described in the rml-io spec (so renaming in the rml-io spec).
Then we would have following alignment:
rr:LogicalTable
> rml:LogicaLSource
rr:BaseTableOrView
> rml:BaseLogicalSource
rr:R2RMLView
> rml:LogicalView
According to me the term view in rr:BaseTableOrView
points to views which are already defined inside the database. Our rml:LogicalView
is more similar to rr:R2RMLView
, being a view defined in the mapping file.
I prefer option 1 because there stuff that's shared between both so we also see this relation in the ontology.
Notes of discussion in TF meeting 7/02/2024:
Preference to go for option 1 and use rml:LogicallyIteralble
as abstract class
with 2 subclasses: rml:LogicalSource
and rml:LogicalView
and the connection to rml:TriplesMap
with properties rml:logicalSource
and rml:logicalView
.
In this case an update in rml-core is needed: each rml:TriplesMap
MUST have exactly one rml:LogicallyIterable
(instead of rml:LogicalSource
).
Other alternative: resonsider rml:LogicalView
as subclass of rml:LogicalSource
and use the property rml:source
also in the shape of rml:LogicalView
(issue #7)
<some_logical_view> a rml:LogicalView;
rml:source <some_logical_source>;
rml:referenceFormulation rml:fields;
rml:field [ rml:fieldName "field_1";
rml:reference "field_1"].
(Maybe the reference formulation can remain implicit?)
Language-wise this last comment feels very clean. Given the final discussion on #7, I have the feeling it's also reasonable definition/ontology-wise, so then I'd vote for "logicalview as subclass of logicalsource", to limit the amount of vocabulary extension we need to do.
See also this discussion. We end up with 3 proposals.
### RML-Core
### http://w3id.org/rml/logicalSource → no change
:logicalSource rdf:type owl:ObjectProperty ;
rdfs:domain :TriplesMap ;
rdfs:range :LogicalSource ;
rdfs:isDefinedBy <http://w3id.org/rml/core/> ;
rdfs:label "logical source" .
### RML-IO
### http://w3id.org/rml/LogicalSource → no change
:LogicalSource rdf:type owl:Class ;
rdfs:comment "Denotes a logical source."@en ;
rdfs:isDefinedBy <http://w3id.org/rml/io/> ;
rdfs:label "Logical Source" .
### iterator → no change
:iterator rdf:type owl:DatatypeProperty ;
rdfs:domain :LogicalSource .
### referenceFormulation → no change
:referenceFormulation rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalSource .
### http://w3id.org/rml/source → no range
:source rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalSource ;
rdfs:range :Source ;
rdfs:isDefinedBy <http://w3id.org/rml/io/> ;
rdfs:label "source" .
### RML-LV
:LogicalView rdf:type owl:Class ;
rdfs:subClassOf :LogicalSource.
### range of rml:source is limited in the shape of the logical view
:LogicalViewShape
sh:targetClass :LogicalView ;
sh:property [
sh:path rml:source ;
sh:node rml:LogicalSource ;
] .
### RML-Core
### http://w3id.org/rml/logicalSource → no change
:logicalSource rdf:type owl:ObjectProperty ;
rdfs:domain :TriplesMap ;
rdfs:range :LogicalSource ;
rdfs:isDefinedBy <http://w3id.org/rml/core/> ;
rdfs:label "logical source" .
### http://w3id.org/rml/LogicalSource → move to core
:LogicalSource rdf:type owl:Class ;
rdfs:comment "Denotes a logical source."@en ;
rdfs:isDefinedBy <http://w3id.org/rml/core/> ;
rdfs:label "Logical Source" .
### iterator → move to core
:iterator rdf:type owl:DatatypeProperty ;
rdfs:domain :LogicalSource .
### referenceFormulation → move to core
:referenceFormulation rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalSource .
### RML-IO
### http://w3id.org/rml/InputLogicalSource → to be added in IO
:InputLogicalSource rdf:type owl:Class ;
rdfs:subClassOf :LogicalSource.
### http://w3id.org/rml/source → domain to be limited to :InputLogicalSource
:source rdf:type owl:ObjectProperty ;
rdfs:domain :InputLogicalSource ;
rdfs:range :Source ;
rdfs:isDefinedBy <http://w3id.org/rml/io/> ;
rdfs:label "source" .
### RML-LV
:LogicalView rdf:type owl:Class ;
rdfs:subClassOf :LogicalSource.
:viewOn rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalView .
### RML-Core
### http://w3id.org/rml/logicalSource → no change
:logicalSource rdf:type owl:ObjectProperty ;
rdfs:domain :TriplesMap ;
rdfs:range :LogicalSource ;
rdfs:isDefinedBy <http://w3id.org/rml/core/> ;
rdfs:label "logical source" .
### http://w3id.org/rml/LogicalSource → move from io to core
:LogicalSource rdf:type owl:Class ;
rdfs:comment "Denotes a logical source."@en ;
rdfs:isDefinedBy <http://w3id.org/rml/core/> ;
rdfs:label "Logical Source" .
### iterator → move from io to core
:iterator rdf:type owl:DatatypeProperty ;
rdfs:domain :LogicalSource .
### referenceFormulation → move from io to core
:referenceFormulation rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalSource .
### http://w3id.org/rml/source → move from io to core
:source rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalSource ;
rdfs:range :Source ;
rdfs:isDefinedBy <http://w3id.org/rml/core/> ;
rdfs:label "source" .
### RML-IO
### http://w3id.org/rml/InputLogicalSource → to be added in IO
:InputLogicalSource rdf:type owl:Class ;
rdfs:subClassOf :LogicalSource.
### RML-LV
:LogicalView rdf:type owl:Class ;
rdfs:subClassOf :LogicalSource.
### range of rml:source is limited in the shape of the logical view
:LogicalViewShape
sh:targetClass :LogicalView ;
sh:property [
sh:path rml:source ;
sh:node rml:LogicalSource ;
] .
@anaigmo your point of view?
I like that with option B and C we can have an abstract description of logical source and its workings in core, where I believe it should be described.
If I look at the most clean and clear solution, I would opt for B. This would keep the domain and ranges of properties simple to reason about.
After looking closely at the proposals and discussions I think I'm more in favor of option B. As @pmaria says, both B and C keep the descriptions or each resource clear, so that the modules don't mess with each other and at the time of writing can be easier to have them differentiated. And between B and C, IMO it's clearer to use different properties since they are different concepts.
I also see a big advantage for simplicity in general terms. The core is now dependant on IO because even the simplest source definition is made in IO, forcing engines to implement the two. If we move the rml:LogicalSource
(and related properties mentioned in option B) we can end up with a core independent of IO, so the simplest source description is supported, which is the one that at least in my case I use the most.
A minor issue, how about renaming rml:viewOn
to rml:viewOnSource
? It's longer, but in RML properties usually describe what comes after
I agree with @anaigmo and @pmaria, and vote for option B.
For the predicate: no strong opinion, however, if we want to describe what comes after, maybe rml:viewOnLogicalSource
(even if that is very long).
But doesn't rml:viewOn
point to rml:Source
? I understand that the point of making the abstract rml:LogicalSource
is to inherit what the rml:LogicalView
needs (e.g. rml:iterator
and rml:referenceFormulation
) and avoid a double step to getting to the source (LV --> S instead of LV --> LS --> S)
But a rml:LogicalView
can only create a view on a rml:LogicalSoure
, not an a plain rml:Source
, therefore I suggested the more specific term. The domain of this predicate would be rml:LogicalView
and the range rml:LogicalSource
.
Hmm then if this is the case and rml:LogicalView
are applied on rml:LogicalSource
, is there a need of having rml:LogicalView
as subclass of rml:LogicalSource
? It wouldn't be inheriting anything from that resource, as it would be referring to the LS that it is applied over, and the link from a triples map can be done extending the range of a property or adding a new one
Agreement, as result of meeting with @pmaria and @anaigmo, to go for option B but to add also :LogicalSource
as range to :viewOn
.
OPTION B: Abstract Logical Source class, subclass InputLogicalSource with predicate rml:source, subclass LogicalView with predicate rml:viewOn
### RML-Core
### http://w3id.org/rml/logicalSource → no change
:logicalSource rdf:type owl:ObjectProperty ;
rdfs:domain :TriplesMap ;
rdfs:range :LogicalSource ;
rdfs:isDefinedBy <http://w3id.org/rml/core/ ;
rdfs:label "logical source" .
### http://w3id.org/rml/LogicalSource → move to core
:LogicalSource rdf:type owl:Class ;
rdfs:comment "Denotes a logical source."@en ;
rdfs:isDefinedBy <http://w3id.org/rml/core/ ;
rdfs:label "Logical Source" .
### iterator → move to core
:iterator rdf:type owl:DatatypeProperty ;
rdfs:domain :LogicalSource .
### referenceFormulation → move to core
:referenceFormulation rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalSource .
### RML-IO
### http://w3id.org/rml/InputLogicalSource → to be added in IO
:InputLogicalSource rdf:type owl:Class ;
rdfs:subClassOf :LogicalSource.
### http://w3id.org/rml/source → domain to be limited to :InputLogicalSource
:source rdf:type owl:ObjectProperty ;
rdfs:domain :InputLogicalSource ;
rdfs:range :Source ;
rdfs:isDefinedBy <http://w3id.org/rml/io/ ;
rdfs:label "source" .
### RML-LV
:LogicalView rdf:type owl:Class ;
rdfs:subClassOf :LogicalSource .
:viewOn rdf:type owl:ObjectProperty ;
rdfs:domain :LogicalView ;
rdfs:range :LogicalSource .
Currently
rml:LogicalView
is defined as ardfs:subClassOf
rml:LogicalSource
. Hence, therml:logicalSource
property is used on a triples map to connect the logical view.This seems plausible, since a logical view has an implicit iterator and a reference formulation. However it becomes problematic when we look at the SHACL shapes. Declaring logical view a sub-class of logical source requires a logical view to have an
rml:source
property as per the logical source shape defined in the io shapes.I see two options: