Alessandro Adamou created STANBOL-656:
-----------------------------------------
Summary: Using non-URI identifiers for recipes causes the rules
not to be stored or exported
Key: STANBOL-656
URL: https://issues.apache.org/jira/browse/STANBOL-656
Project: Stanbol
Issue Type: Bug
Components: Rules
Affects Versions: 0.9.0-incubating
Reporter: Alessandro Adamou
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).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
