search

kg-construct / rml-lv

Specification repository for logical views in RML.
https://kg-construct.github.io/rml-lv/dev.html
3 stars 3 forks source link

rml:LogicalView as sub-class of rml:LogicalSource complications #14

Closed pmaria closed 2 months ago

pmaria commented 7 months ago

Currently rml:LogicalView is defined as a rdfs:subClassOf rml:LogicalSource. Hence, the rml: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:

  1. We keep the current thinking that a logical view is a sub-class of logical source, and introduce an abstract class to separate the source property.
rml:LogicallyIterable a owl:Class ;
  # class that can have a rml:iterator and rml:referenceFormulation, explicit or implicit.
.

rml:LogicalSource a owl:Class ;
  rdfs:subClassOf rml:LogicallyIterable ;
  # Logically iterable and must have an rml:source.
.

rml:LogicalView a owl:Class ;
  rdfs:subClassOf rml:LogicallyIterable ;
  # Logically iterable and has view properties.
.
  1. We disregard the notion that logical view is a sub-class of logical source, and introduce a new property to connect the triples map to the view.
rml:logicalView a owl:ObjectProperty ;
  rdfs:domain rml:TriplesMap ;
  rdfs:range rml:LogicalView ;
.
pmaria commented 7 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.

elsdvlee commented 7 months ago
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.

andimou commented 7 months ago

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.

elsdvlee commented 7 months ago

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.

DylanVanAssche commented 7 months ago

I prefer option 1 because there stuff that's shared between both so we also see this relation in the ontology.

elsdvlee commented 7 months ago

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).

elsdvlee commented 7 months ago

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?)

bjdmeest commented 7 months ago

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.

elsdvlee commented 5 months ago

See also this discussion. We end up with 3 proposals.

OPTION A: Logical View is a subclass of Logical Source

### 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 ;
     ] .

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 .

OPTION C: Abstract Logical Source class with predicate rml:source, subclasses InputLogicalSource and 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 ;
     ] .
elsdvlee commented 5 months ago

@anaigmo your point of view?

pmaria commented 5 months ago

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.

anaigmo commented 5 months ago

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

elsdvlee commented 5 months ago

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).

anaigmo commented 5 months ago

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)

elsdvlee commented 5 months ago

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.

anaigmo commented 5 months ago

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

elsdvlee commented 2 months ago

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 .