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