No URI rand() generation for OWL projects ?

[Thomas Francart]

Hello

In VB 12.1.0, when working in a OWL project, and when creating a new instance, VB does not propose to auto-generate the URI automatically. IOW I don't see the placeholder "Leave empty in order to autogenerate a random URI", and users are forced to enter something. (same thing when I try to create a new class).

At project creation time I leave the default "URI generator", which in my understanding is the "Native template-based URI generator", which should default to "${xRole}_${rand()}" in the case the entity being created is not a Concept or a xLabel.

I also tested by manually setting the "Native template-based URI generator" at project creation time, which didn't changed anything.

How can I have all URI autogenerated in an OWL project ?

Thanks

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,

 

it is possible to customize that but, apologies, it has not yet been documented properly (it’s been an addendum some time ago).

 

The default setting comes from the assumption that, in general, ontologies are the equivalent of programming languages for world modeling and a good rule in programming is to use evocative names. In programming the rule seems to still hold and multilinguality as a rationale for breaking it is not popular (I don’t know a single person who is happy about Excel’s localized function names). A better point could be about the possible dynamicity of the words used to address a concept but, for those extreme cases, well owl:sameAs and deprecation would work… and SPARQL with code names (or necessity to always refer to labels) gives headache (yes we do for thesauri already ;-) )

So, besides the due intro with historical reason, and without taking any stance in the secular debate on whether this rule really holds also in the ontology world (plus, you mentioned instances, which yet is a different case from classes), let me go to the solution:

 

The default behavior of the form can be overridden by rewriting the resource construction (which, if not specified, simply follows the standard form construction).

 

resource uri(coda:randIdGen("class", {})) .

 

resource in custom forms is a reserved word and denotes the resource being constructed by the custom form.

 

If you are curious about various “special” possibilities, the basic template available in the custom forms should provide you with relevant information. Here’s the excerpt related to the nodes section:

 

                              //uri of the new resource

                              resource uri stdForm/resource .

 

                              //type of the new resource

                              type uri stdForm/type .

                             

                              //in case of SKOS project, the label of the resource is a simple literal

                              label literal stdForm/label .

                             

                              //in case of SKOSXL project, the label of the resource is a skosxl:Label composed by its URI and a skos:literalForm

                              xLabel uri stdForm/xLabel .

                              lexicalForm literal stdForm/lexicalForm .

                             

                              //language tag of the label

                              labelLang literal stdForm/labelLang .

 

                              //iri of the resource being enriched with the graph generated by the custom form (available only for custom ranges)

                              subject uri formCtx/subject .

                             

                              //the user logged in the current session can be referenced too

                              user uri session/user .

 

Pls notice that all the node names are arbitrary and the relevant information there is the special source (using stdForm, formCtx or session). The exception there is exactly “resource” which, if overridden, alters the creation of the node.

 

And now, wearing my hairshirt…known limitations :-)

• If you override resource (at least for those resources you associated the cform with), then you get the converter you picked. You don’t have in any case the double alternative for which you can type the name OR have it automatically assigned (if I’m not missing anything from that customization addendum we did…)
• If you want to override for all classes (creating random class names, then it’s easy, you simply put owl:Class in the association). If you want to override for instances, currently it’s pretty annoying, as you have to name specifically all classes for which the association holds (we do not resolve type transitive closure on CForm associations)

 

Kind Regards,

 

Armando

 

P.S. just a clarification on your settings for the URI generator. That sets the setting for the URI generator…wherever it is being used (so to have a consistent usage), but it doesn’t enable it per se

 

 

--
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/CAPugn7ViX-eVO3tRkcodAeKqt50k2i5uBCCOOr0Nopd6MLZ1Tg%40mail.gmail.com.