Usage of Identifiable abstract class

[ndr-brt]

Currently, an abstract class Identifiable exists in the policy-evaluator module, and it's extended by all the Policy model classes (Policy itself, and Rule, which is in turn extended by Permission, Duty and Prohibition.

That Identifiable is not really used, there are no abstractions that requires only the Identifiable type instead of the concrete types, so it could be removed probably.

However an Identifiable abstraction used also on other entities in the codebase (as TransferProcess, ContractNegotiation and so on) could help describe better interfaces, e.g. on the Store side, permitting us to have an Identifiable store that offer the findById, save and deleteById methods and to keep the (at that point) extending *Store interfaces more succint.

In this case, I would propose to rename uid to id and getUid to getId

[sebbader]

I assume the uid field comes from the ODRL vocabulary (https://www.w3.org/TR/odrl-vocab/#term-uid). Honestly, I have never understood why the ODRL WG has defined this property at all. Anyway, I support the suggestion for using id and *ById() methods. In particular as ODRL is an RDF vocabulary, and RDF natively treats it's entities as (IRI) identifiers.
Sounds a bit more complicated as it is: Any ODRL entity should be globally 'identifiable', so should be the instances of the respective classes in the EDC. Using an ID mechanism brings us closer to the W3C standards, which is a good thing.

[sebbader]

Further small issue: 'Identifiable' is a defined term in the AAS world, similar to 'Asset'. Using this as a name of the interface will create a bit of confusion... At least we need to be aware of this fact and explain the differences.