Custom View query not reading labels ?

68 views
Skip to first unread message

Thomas Francart

unread,
Aug 28, 2024, 12:24:29 PM8/28/24
to vocbench-user
Hello

I have setup a custom view, with a "Dynamic Customizable Vector Model", with a SPARQL query.

The following SPARQL query works - note how it selects the URI of the "dct:type" predicate:

```
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?pivot ?label_en_value ?label_fr_value ?type_value ?date_value WHERE {
$resource $trigprop ?pivot .
?pivot skos:prefLabel ?label_en_value .
    FILTER(lang(?label_en_value) = "en")
OPTIONAL {
?pivot skos:prefLabel ?label_fr_value .
        FILTER(lang(?label_fr_value) = "fr")
}
OPTIONAL {
?pivot dct:date ?date_value .
}
OPTIONAL {
?pivot dct:type ?type_value .
}
}
```

However, I want users to see not the URI of the type, but the (english) label of the type. So I tried the following SPARQL query, which does not work (the label of the type is not returned) - note how it selects the prefLabel of the dct:type predicate:

```
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?pivot ?label_en_value ?label_fr_value ?type_label_value ?date_value WHERE {
$resource $trigprop ?pivot .
?pivot skos:prefLabel ?label_en_value .
    FILTER(lang(?label_en_value) = "en")
OPTIONAL {
?pivot skos:prefLabel ?label_fr_value .
        FILTER(lang(?label_fr_value) = "fr")
}
OPTIONAL {
?pivot dct:date ?date_value .
}
OPTIONAL {
?pivot dct:type ?type .
?type skos:prefLabel ?type_label_value .
FILTER(lang(?type_label_value) = "en")
}
}
```

I am positive that the query works because I try it in the SPARQL form by replacing the $resource and $trigprop placeholders by actual values. It works and it returns the label of the type.

The label of the type actually comes from an imported project, if that matters (so it is actually in a separate named graph). But really the strange thing is that the custom view query does not work when asked to return the label, while I can see it works when ran manually.

What could prevent the custom view to read this property ? are custom views restricted on the scope of the data they operate on ?

Thanks !
Thomas

--

Thomas Francart - SPARNA
linked data | domain ontologies | knowlegde graphs
blog :
blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel : 
 +33 (0)6.71.11.25.97

Roland Wingerter

unread,
Aug 29, 2024, 12:55:34 PM8/29/24
to vocbench-user
Dear Thomas,
according to the documentation the $resource and $trigprop variables must be returned by the SPARQL query. 
Kind regards
Roland

Roland Wingerter

unread,
Aug 30, 2024, 4:52:19 AM8/30/24
to vocbench-user
Dear Thomas,
I made a test and can confirm the issue: A label from an (owl:)imported project will not be displayed in the custom view. 
The custom view works as expected when I load the data from the other project (even to a separate graph).
Kind regards
Roland

Roland Wingerter

unread,
Aug 30, 2024, 5:30:35 AM8/30/24
to vocbench-user
Correction: I was mistaken when I wrote "(even to a separate graph)".

Thomas Francart

unread,
Sep 1, 2024, 10:16:12 AM9/1/24
to Roland Wingerter, vocbench-user
Thank you Roland, but I tried that, and it is not the cause of the issue.
The documentation says that what must be returned is "the variable representing the object of the $resource $trigprop pair", which is the ?pivot variable in my case and it is properly returned.

I am now positive that this has to do with imports : the query works fine when all the data (instances + type vocabulary) is in the same project. But the query does not work as expected when the type vocabulary is in an imported project. My hypothesis is that the custom view query is executed only against the data of the current project and does not see the data from imported projects.

Please find below a reproductible test case:

# Scenario that works

1. Import this data in a single project

```
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix mytypes: <https://data.example.org/authority/mytypes/> .
@prefix myinstances: <https://data.example.org/authority/myinstances/> .
@prefix myontology: <https://data.example.org/myontology/> .

### Type SKOS vocabulary

mytypes:scheme a skos:ConceptScheme .

mytypes:c_A a skos:Concept ;
skos:topConceptOf mytypes:scheme ;
skos:inScheme mytypes:scheme ;
skos:prefLabel "Type A"@en ;
skos:prefLabel "Type A"@fr ;
.

mytypes:c_B a skos:Concept ;
skos:topConceptOf mytypes:scheme ;
skos:inScheme mytypes:scheme ;
skos:prefLabel "Type B"@en ;
skos:prefLabel "Type B"@fr ;
.

### OWL ontology

myontology:Person a owl:Class .

myontology:children a owl:ObjectProperty .

### Instances

myinstances:i_1 a myontology:Person ;
myontology:children myinstances:i_11, myinstances:i_12, myinstances:i_13 ;
skos:prefLabel "Person 1"@en ;
dct:type mytypes:c_A ;
.

myinstances:i_11 a myontology:Person ;
skos:prefLabel "Person 1.1"@en ;
dct:type mytypes:c_A ;
.

myinstances:i_12 a myontology:Person ;
skos:prefLabel "Person 1.2"@en ;
dct:type mytypes:c_B ;
.

myinstances:i_13 a myontology:Person ;
skos:prefLabel "Person 1.3"@en ;
# no type
.
```

2. Configure custom view with the following query and associate it to the "children" property:

```
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?pivot ?label_en_value ?type_label_value WHERE {

    $resource $trigprop ?pivot .
    ?pivot skos:prefLabel ?label_en_value .
    FILTER(lang(?label_en_value) = "en")
    OPTIONAL {
        ?pivot dct:type ?type .
        ?type skos:prefLabel ?type_label_value .
        FILTER(lang(?type_label_value) = "en")
    }
}
```

3. Look at instance "Person 1", the table is displayed correctly, with the labels of the types:

image.png



# Scenario that does NOT works

the same data as before is splitted in 2 projects, types and instances. The instances project imports the types project. The custom view query is identical.

1. Create project "Types" and import the following data:

```
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix mytypes: <https://data.example.org/authority/mytypes/> .
@prefix myinstances: <https://data.example.org/authority/myinstances/> .
@prefix myontology: <https://data.example.org/myontology/> .


### Type SKOS vocabulary

mytypes:scheme a skos:ConceptScheme .

mytypes:c_A a skos:Concept ;
skos:topConceptOf mytypes:scheme ;
skos:inScheme mytypes:scheme ;
skos:prefLabel "Type A"@en ;
skos:prefLabel "Type A"@fr ;
.

mytypes:c_B a skos:Concept ;
skos:topConceptOf mytypes:scheme ;
skos:inScheme mytypes:scheme ;
skos:prefLabel "Type B"@en ;
skos:prefLabel "Type B"@fr ;
.
```

2. Create project "Instances" and import the following data:

```
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix mytypes: <https://data.example.org/authority/mytypes/> .
@prefix myinstances: <https://data.example.org/authority/myinstances/> .
@prefix myontology: <https://data.example.org/myontology/> .


### OWL ontology

myontology:Person a owl:Class .

myontology:children a owl:ObjectProperty .

### Instances

myinstances:i_1 a myontology:Person ;
myontology:children myinstances:i_11, myinstances:i_12, myinstances:i_13 ;
skos:prefLabel "Person 1"@en ;
dct:type mytypes:c_A ;
.

myinstances:i_11 a myontology:Person ;
skos:prefLabel "Person 1.1"@en ;
dct:type mytypes:c_A ;
.

myinstances:i_12 a myontology:Person ;
skos:prefLabel "Person 1.2"@en ;
dct:type mytypes:c_B ;
.

myinstances:i_13 a myontology:Person ;
skos:prefLabel "Person 1.3"@en ;
# no type
.
```

3. Add an import "from Local Project" from project "Instances" to import the project "Types".

4. Create the custom view exactly as before, on the property "children", with the same query.

5. Look at instance "Person 1", the "type_label" column is not filled in:

image.png





--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/d62dbae2-a003-42a8-a545-aa8a76ab70b2n%40googlegroups.com.

Roland Wingerter

unread,
Sep 3, 2024, 8:33:07 AM9/3/24
to vocbench-user
Dear Thomas,

Thank you for the elaborate example. It underlines your hypothesis that the custom view does not see the data from an owl:imported project. My initial answer was wrong, I misunderstood the documentation.

Kind regards
Roland

stel...@uniroma2.it

unread,
Sep 4, 2024, 5:30:34 AM9/4/24
to Roland Wingerter, vocbench-user

Dear Thomas,

 

apologies for the late reply. We were verifying this as, indeed, we just had to unfold past discussions and checks over the situation.

 

By first, I confirm, as Roland did, the situation.

 

A bit of history then:

 

After introducing the custom views, we realized that there was a complication when dealing with validation. As you probably know, validation implies both triples being written in the support repository (reified, with all metadata of the commit action) and in the core one (for preview, this is the problematic part).

Furthermore, we had the additional requirement given by the possibility we introduced to edit distant values (i.e. values shown through a custom view of a resource, but not being directly linked to that resource) directly from the custom view.

I skip the details of that, but this led to:

  1. A detailed addressing of the phenomenon for property-chains-driven custom views (you can use them and they should work)
  2. A postponed plan to address it for SPARQL driven custom views, where this limitation exists.

 

We will make it more clear (until we deal with it for good) in the editor for cviews.

 

With added apologies for not having it clarified earlier,

 

Armando

 

 

 

 

 

 

Thomas Francart

unread,
Jun 26, 2026, 10:48:12 AM (10 days ago) Jun 26
to stel...@uniroma2.it, Roland Wingerter, vocbench-user
Hello

I am resurrecting this thread to inquire if there has been any progress on the ability to execute Vector custom views SPARQL queries on all the imported projects ? (in order to fetch labels of entities from imported projects)
The current limitation hinders the usage of Vector custom views as, most of the time in my use-cases, they would refer to entities from other projects.
I also don't really understand why the Single-value custom view is able to display values from imported project, while the vector view cannot.

As I understand this limitation has to do with the ability to edit directly the values in the table (which would fail if the value comes from another project), could the following be implemented as a workaround :
  1. SPARQL query would be executed against all the owl:import-ed project data
  2. By default, editing from the table would be impossible
  3. The custom view editor would enable editing explicitly if he/she knows where the data comes from

Or any other option that would allow the query to work across projects, as this is more important in my use-case than the ability to edit the values inside the table.

Thanks for considering this use-case !
Thomas





--

Thomas Francart - SPARNA
linked data | domain ontologies | knowledge graphs
blog :
blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel : 
 +33 (0)6.71.11.25.97
Reply all
Reply to author
Forward
0 new messages