Hi Tobias,

    * Straightforward answer: 


In the XML (or whatever format) introduce two types of identifiers :
local ID ( e.g. CDK_topoShape) and global URI 
(http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/feature_definition/CDK_topoShape)


example (not synchronized with API)

<compound id="XXX">
    <link href="http://opentox.org/compound/XXX">
    <feature_definition id="YYY">
        <link href="http://opentox.org/feature_definition/YYY">
        <feature>3.14</feature>
    </feature_definition>
</compound>

URI like this one 
/feature/compound/{cid}/feature_definition/{f_def_id}  will assume to be
expanded by local ID only. This should happen only server side, e.g. the
client itself should not construct URI, they should be returned by the
server (this is what /Hypermedia as the Engine of Application State
/means, isn't it).

That said, localID is most probably redundant, but sometimes might be
useful. 

An interesting example is below. Do you see any issues with mixing
references from different sites?

<compound id="XXX">
    <link href="http://opentox.org/compound/XXX">
    <feature_definition id="ZZZ">
        <link href="http://yoursite.org/feature_definition/ZZZ">
        <feature>3.14</feature>
    </feature_definition>
</compound>

    * More complex answer :

We are exploring the space of distributed REST applications (many
services, running on different servers) and naming of distributed
objects, which is far from trivial.  Most of the REST hype is only about
single REST application, running on a single machines (or a cluster of
machines) under single administrative authority.  This is not the case
with OpenTox.

One way is to make use of RDF in order to define that two (or more) URI
point to the same object  e.g. http://opentox.org/compound/benzene and
http://myservice.org:9999/compound/c1ccccc1  mean the same chemical
compound.   RDF and ontologies  (descriptor ,endpoints, etc.) can help
to ensure the services are talking about the same objects , but there
are still caveats. 

Best regards,
Nina

Tobias Girschick wrote:
> Hi,
>
> While revising the API 1.0 there arose some controversy about IDs for
> features, feature definitions, references and so on.
>
> As far as we I know there has been no definitive decision made up to
> now. Please correct me if I am wrong here.
>
> What we are using at the moment as IDs for feature definitions and
> references is full URIs, e.g. something like this:
>
> http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/feature_definition/CDK_topoShape
> http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/reference/CDK_topoShape
>
> This seems to be very nice and useful. But there arises one conflict
> with feature IDs as the API specifies the following URI to GET a
> specific feature:
> /feature/compound/{cid}/feature_definition/{f_def_id}
>
> The URI won't work if I just blindly insert the compound or feature
> definition ID here, as they both are fully qualified URIs. 
>
> If we use just something like CDK_topoShape as ID instead of a URI, we
> have the problem that this would have to be unique over the whole
> OpenTox system to prevent mix ups.
>
> Is there a clever way to solve this?
>
> Regards,
> Tobias
>
>