SKOS rendering engine with non-SKOS properties requires prefixed URI

[Thomas Francart]

Hello

I am trying to customize a SKOS rendering engine to concatenate a custom property in front of the label. Basically what I am trying to achieve is what is described at https://semanticturkey.uniroma2.it/doc/sys/rendering_engine.jsf and also clarified in the discussion at https://groups.google.com/g/vocbench-user/c/rHYFrRXwkMU/m/FIYnncTTBAAJ - just with a custom property in my own namespace instead of skos:notation.

I can perfectly have it working when I try with the full URI of skos:notation "http://www.w3.org/2004/02/skos/core#notation" (so just like the example), but if I put the full URI path of my own property, it does not show up. However if I use the *prefixed* variant (e.g. xxx:myProp), then it works ! shouldn't it be working with the full URI of my custom property, since it works with the full URI of SKOS properties ?

Cheers

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

[stel...@uniroma2.it]

Dear Thomas,

 

Thanks for reporting it. I’d say it looks like a bug, a quite mysterious one :-)

 

By first, as nothing is hard-coded with skos:notation (we only used it in the example because it’s a very common case), we have to understand why it works with skos:notation and not with yours. The only discriminant that comes to my mind is: is your property part of a vocabulary that is physically imported in the project? I see you mentioned the prefixed form (qname), but this could be obtained by just adding a prefix-namespace mapping, even without importing the ontology.

So, I’m just asking this to isolate more the phenomenon; how this implies the issue you mention and the way it happens (I would understand qnames not working while URIs do, not the opposite) is a whole thing we have to look into :-D

 

Kind Regards,

 

Armando

 

--
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 visit https://groups.google.com/d/msgid/vocbench-user/CAPugn7W3B404e3rhi3aM5AtSR1ojdk5jF%3D6FmJrCrY0o9rQJ-Q%40mail.gmail.com.

[Thomas Francart]

Hello

Le mer. 24 juin 2026 à 14:25, <stel...@uniroma2.it> a écrit :

Dear Thomas,

 

Thanks for reporting it. I’d say it looks like a bug, a quite mysterious one :-)

 

By first, as nothing is hard-coded with skos:notation (we only used it in the example because it’s a very common case), we have to understand why it works with skos:notation and not with yours. The only discriminant that comes to my mind is: is your property part of a vocabulary that is physically imported in the project? I see you mentioned the prefixed form (qname), but this could be obtained by just adding a prefix-namespace mapping, even without importing the ontology.

Yes the qname is declared as an explicit prefix in this project, and the ontology project is imported from this project.

Cheers

Thomas

[Manuel Fiorelli]

Hello Thomas,

I was not able to reproduce your issue using a local project with the SKOS model and the SKOS lexicalization model.
Could you share with us — even privately — a small test case that would help us replicate the problem?

Regards,

Manuel

To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/CAPugn7XXsrbEw5EeOj2DW7J%2BB1E-v2pPSyrj65BnXzKAS0%2B%3DUA%40mail.gmail.com.

--

Manuel Fiorelli

[Thomas Francart]

Thank you Manuel for trying to reproduce this behavior.

We are experiencing strange behaviors with the customisation of the SKOS rendering engine. The fact that it worked with the prefixed version of the URI happened on 2 different environments... but then after some reimport of the data, it was the opposite : it worked with the full URI ! so I don't know what happened and cannot provide a test case for this.

But now we observe something different: the SKOS rendering engine (with full URIs) works before data is validated, but does not work after data has been validated.

This time I provide a reproducible test case below.

1. Create a new project, Model SKOS, lexicalisation SKOS, with validation enabled.

2. Load the SKOS data provided below **without implicit validation of the data**

3. Configure SKOS rendering engine on the project this way:

  3.1 pattern (${order} - )?${labels}

  3.2 variable "order" set to http://example.eu/onto#order

  Then submit.

4. Reopen the project, check that this is working, the order is prepended to the label in the tree, before C1.1 and C1.2 (there is none on C1, on purpose) :

5. Now validate the data

6. Refresh the tree, and now the order has disappeared:

I then tried to reset the SKOS rendering configuration, and recreate it again with the above setup, but it would not work.

Any idea ? 

Thanks !

Thomas

```turtle

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ex: <http://example.eu/> .

ex:TheScheme a skos:ConceptScheme ;
skos:prefLabel "The scheme"@en;
skos:hasTopConcept ex:C1;
.

ex:C1 a skos:Concept ;
skos:prefLabel "C1"@en;
skos:topConceptOf ex:TheScheme ;
skos:inScheme ex:TheScheme ;
skos:narrower ex:C11 ;
skos:narrower ex:C12 ;
.

ex:C11 a skos:Concept ;
skos:prefLabel "C1.1"@en;
skos:broader ex:C1 ;
skos:inScheme ex:TheScheme ;
<http://example.eu/onto#order> "1" ;
.

ex:C12 a skos:Concept ;
skos:prefLabel "C1.2"@en;
skos:broader ex:C1 ;
skos:inScheme ex:TheScheme ;
<http://example.eu/onto#order> "2" ;
.

```