Automatically using different URI-patterns within a project

[Frank Nebel]

Hello,

first of all I want start with a thank you for making this software open-source.

My particular question is about URI-patterns. More precisely, I would like to distinguish between concepts and individuals (of those concepts) within a project.

For example, I have a baseURI "http://orgX.example.net/domain" and I want to create a vocabulary for this particular domain (with dozens of concepts and corresponding instances). Ideally, I now would like to distinguish between

- concepts (e.g. "fruit") with an URI: "http://orgX.example.net/domainY/schema#fruit"

- individuals (e.g. "apple") with an URI: " http://orgX.example.net/domainY/individual/fruit#apple"

This allows me to keep a better grasp on large domains.

In VocBench, this can all be done manually by using the "Lock/Unlock" feature. However, I would like to hide this from my users and generate it automatically. Is there any way to achieve this?

I thought about using "Custom Forms", but this does not seem to work, because the newly created individual automatically takes the stdForm/resource URI. Is there any way to generate a form without the initial "URI" header? Thus, a form that allows one to generate the URI from user input (on fields)? In my particular case

"http://orgX.example.net/domainY/individual/fruit#" + $user input (e.g. apple)

-->  http://orgX.example.net/domainY/individual/fruit#apple"

With Sheet2RDF this is all possible without problems.

Thank you!

Kind regards,

Frank

[Armando Stellato]

Dear Frank,

 

very short answer as I’m getting into a meeting (but quick, so you can start playing with it :-) )

 

Look here:

http://vocbench.uniroma2.it/doc/user/projects.jsf#project_creation

for “URI Generation”. You will see where to activate the configuration for the URI generator at project creation.

 

Then, that section points you to the semantic turkey page for details about the URI generator.

 

If you need further help, pls do not hesitate to ask.

 

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 on the web visit https://groups.google.com/d/msgid/vocbench-user/debe0dfe-339b-420a-a715-fb0860ba48efn%40googlegroups.com.

[Frank Nebel]

Dear Armando,

Thank you so much for your quick response. I started to play around with the URI Generator, but unfortunately did not get far. I probably do not have a firm enough grasp of vocBench to make it work. Do you have any examples (can be quick and dirty) that would help me get on the right path?

Apart from this, I would like to clarify that I understood your hint correctly:

1) First, I would need to either configure an existing URI-Generator or implement a new URI-Generator. This URI-Generator is then attached to a project (on creation). For my particular project, based on RDFS/RDFS, it is probably the latter, because the exting URI-Generators seem to be for SKOS only (xLabel, concept, xNote, fallback). Is this assumption correct?

2) Every time a new concept or individual (in case of RDFS) is instantiated within VocBench, an URI for this concept/individual is generated automatically (adhering to the pattern of the provided URI-Generator). Thus, in case of a newly instantiated individual "apple", a fully randomized URI (e.g. "concept_34FE2398") would be generated and then assigned to this individual. Indeed, this is the current pattern for the Native template-based URI-Generator (having pattern "c_${rand()}).

Regarding step (2), I have an additional question. In the documentation it says that URI-Generators must have some form of randomness to avoid entering a potential infinite loop (this is part of a warning). Does this restriction still apply? Because when it does, then I cannot achieve my original goal to generate different URIs for concepts and individuals, like ...

- concepts (e.g. "fruit") with an URI: "http://orgX.example.net/domainY/schema#fruit"

- individuals (e.g. "apple") with an URI: " http://orgX.example.net/domainY/individual/fruit#apple"

I general, I am not yet sure about, if the URI-Generator mechanism would really allow me to ask a VocBench user for the intended surface form/label of a new individual, e.g. "apple", from within a custom form and then to assign the right URI "http://orgX.example.net/domainY/schema#fruit" to this individual.

Apologies for all my questions, but I am really stuck and I would be very grateful for some breadcrumbs towards a solution.

Kind regards,

Frank

[Armando Stellato]

Dear Frank,

 

Apologies for taking some time to reply. You will see later on in the msg why I took some time,.

 

Now that I have read your second email, I may realize that I didn’t get your original message. I thought that you original case with “fruit” was indeed only a generic example, while it was really the pattern you wanted.

So, you want to really do something like:  I choose “fruit” as a label for a concept, and I get, say, <baseuri>/concept#fruit

And there are two points there:

• Being able to automatize the construction of part of the baseuri
• Be able to assign a same token (e.g. fruit) to both the label and the local part of the URI

 

Bad news first: unfortunately, this can’t be done now. The reason is that we have two applications of custom forms: custom constructors (CCs) and custom ranges (CRs). CRs (association of a form to a property) build everything from scratch, custom constructors are associated to a given class (or type of resource, as concepts, for any class from skos:Concepts to any of its children) and act in overlaying over the standard form that is provided by the application. What you need is to not use the standard form at all, so not in overlaying, but building the form from scratch, as it is in CRs.

An escamotage could be to use then custom ranges, using a fictious individual (and a property for that) as a factory for building new resources which can be assigned (even automatically, to their class). It can indeed be done, and you could use different properties for different classes. However, it seems to me not really practical, and would ask for the editor to clean these properties once in a while.

 

Indeed, your point touched some revision that we had already in plan for the next release. I think it might actually be a use-case for the more general revised perspective on CFs that we are building. Since, as I can see, you can still edit these URI shapes manually, but would obviously prefer some automation, I can tell you this: if everything goes well, the planned improvement should come up with the next release of VB3 scheduled for end of April (first days of May at most). Your use-case has been taken as a target proof for the improvement.

[Frank Nebel]

Dear Armando, 

Thank you for your detailed reply.

Now that I have read your second email, I may realize that I didn’t get your original message. I thought that you original case with “fruit” was indeed only a generic example, while it was really the pattern you wanted.

So, you want to really do something like:  I choose “fruit” as a label for a concept, and I get, say, <baseuri>/concept#fruit

And there are two points there:

• Being able to automatize the construction of part of the baseuri
• Be able to assign a same token (e.g. fruit) to both the label and the local part of the URI

I think we have a common understanding now. However, to avoid misunderstandings, I would expand my example a bit more to have complete transparency

baseURI:http://orgX.example.net/domainY

For creating OWL/RDFS concepts, I currently use the standard Create Class feature, which automatically generates the following URLs

• http://orgX.example.net/domainY#fruit (entering "fruit" within the text field)
  
• http://orgX.example.net/domainY#vegetable (entering "vegetable" within the text field)
  

This is all fine. Clearly, I would appreciate a feature that automatically adds "/concept" to the URL, but it is not strictly necessary to automatically generate those URLs (only a nice to have right now): 

• http://orgX.example.net/domainY/concept#fruit (entering "fruit" within the text field )
  
• http://orgX.example.net/domainY/concept#vegetable (entering "vegetable" within the text field)

For me, it is much more important to have such a feature for the creation of instances (for these OWL/RDFS concepts). Here, I would definitely appreciate the following behaviour:

• http://orgX.example.net/domainY/instance/fruit#apple (marking concept "fruit" and clicking on feature "Create Instance"; then after entering "apple" within the text field, the URL is automatically generated and used as a unique identifier for the instance "apple")
  
• http://orgX.example.net/domainY/instance/vegetable#carrot (marking concept "vegetable" and clicking on feature "Create Instance"; then after entering "carrot" within the text field, the URL is automatically generated and used ...)

Motivation: This structuring of an URL (coupled with automated URL-generation within VocBench) would allow me to work nicely with very large domains (with many concepts and even more instances). It makes it also much easier for less experienced users in ontology/vocabulary management to add new instances. Without it, most people will most likely forget to adapt the URL manually (resulting in a mess and potential conflicts between instances (with same IDs for example)).

 

Bad news first: unfortunately, this can’t be done now. The reason is that we have two applications of custom forms: custom constructors (CCs) and custom ranges (CRs). CRs (association of a form to a property) build everything from scratch, custom constructors are associated to a given class (or type of resource, as concepts, for any class from skos:Concepts to any of its children) and act in overlaying over the standard form that is provided by the application. What you need is to not use the standard form at all, so not in overlaying, but building the form from scratch, as it is in CRs.

An escamotage could be to use then custom ranges, using a fictious individual (and a property for that) as a factory for building new resources which can be assigned (even automatically, to their class). It can indeed be done, and you could use different properties for different classes. However, it seems to me not really practical, and would ask for the editor to clean these properties once in a while.

 

Indeed, your point touched some revision that we had already in plan for the next release. I think it might actually be a use-case for the more general revised perspective on CFs that we are building. Since, as I can see, you can still edit these URI shapes manually, but would obviously prefer some automation, I can tell you this: if everything goes well, the planned improvement should come up with the next release of VB3 scheduled for end of April (first days of May at most). Your use-case has been taken as a target proof for the improvement.

If my extended example (from above) still benefits from this new release (as described above), I would be absolutely happy. This is the last "issue" that keeps me from using VocBench in my project. :-)

Thanks again for your efforts!

Best

Frank