[STANBOL-656] Using non-URI identifiers for recipes causes the rules not to be stored or exported

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 0.9.0-incubating
• Component/s: Rules
• Assignee: Unassigned
• Reporter: Alessandro Adamou
• Created: 05/Jun/12 13:11
• Updated: 05/Jun/12 13:11

Description

Clerezza UriRef is now the class used for recipe IDs. This in principle should allow the definition of simple IDs, which are legal UriRefs.

However, when a recipe is created with an ID which is not a fully qualified URI, the store silently fails to store them, and refactoring also fails.

For example, if I create a recipe "r1" with rule "a", Stanbol tries to add a triple:

<r1> <http://incubator.apache.org/stanbol/rules/hasRule> <r1/a>

subject and object are not URIs and the triple is not present when I GET [stanbol-host]/rules/recipe/r1

On the other hand if I create the recipe "http://example.org/recipes/r1" the correct triple (also with a URI in the object) is added and refactoring works.

A decision should be taken on how to handle non-URI recipe IDs. Either

(a) we disallow non-URIs (again), but this would lead to unnecessarily lengthy RESTful resources, or

(b) we allow both URIs and non-URIs, and when recipe export as RDF is required we check if it is a URI: if so, the "recipe individual" is exported as it is, otherwise the namespace from the Rule store configuration (or the Stanbol endpoint) is added

(c) we only allow non-URIs (e.g. as for scopes and session in OntoNet). we store rules and recipes in Clerezza with a different, "private" URI identifier but keep track of what would be the non-URI id. When someone requests the recipe as RDF via the REST API (or calls refactoring services), the recipe and riule individuals are created on the fly using the Stanbol host endpoint as the namespace (or the configured namespace if the service is called via the Java API instead of REST).