Specifying a LocalResource with non-singleton Range gives wrong type

[nilsjor]

In particular, when the cardinality of the range is larger than one, the class attribute corresponding to the resource property becomes a Link.

The preferable behavior would be to type it as the nearest common superclass.

[jadelkhoury]

@berezovskyi I need your help recalling how to best deal with java class inheritance when it comes to JMH.

Currently, a property with (a) LocalResource valueType, and (b) range pointing to multiple resources will result in a Java property whose type is "Link".
This of course is not a good mapping, since Link is meant to be for non-local resources.

I aimed to solve this by map the java property to an AbstractResource.
However, JMH complains (rightly) since AbstractResource does not have the OSLC annotations, so that JMH can workout how to marhsell/unmarshell.

New suggested approach:
define a new class in oslc.core AbstractLocalResource, that can have the expected OSLC annotations.

But 2 questions first:

• @berezovskyi : Was there a problem when a property defines its type to be AbstractLocalResource, yet at runtime, the property points to an instance of a subtype of AbstractLocalResource?
• @nilsjor if I implement this change, do you have real scenario we can use to test this still?

[jadelkhoury]

@nilsjor Not because I want to avoid this problem, but I wonder if you should really consider using a real (not local) resource, yet define the OslcRepresentation to be "inline". Would you get what you want?

[berezovskyi]

@jadelkhoury which annotations are you planning to add to AbstractLocalResource?

Please see https://github.com/eclipse/lyo.core/blob/master/oslc4j-jena-provider/src/test/java/org/eclipse/lyo/oslc4j/provider/jena/resources/Person.java#L29 for the kind of inheritance scenario that will be supported in Lyo 4.0. This is in line with the suggestion from @nilsjor to use the closest superclass for that field.

If two range classes have nothing in common except for rdf:Resource, I recommend using my hack in JMH or somewhere in the generated code to try deserialisation in the order: https://github.com/EricssonResearch/scott-eu/blob/master/lyo-services/webapp-twin-robot/src/main/java/se/ericsson/cf/scott/sandbox/twin/xtra/PlanExecutionService.kt#L80

[sgarfinkel]

A suggestion: This is a perfect use-case for the visitor pattern. Generate a base, per-domain subclass of AbstractLocalResource that has an accept(<DomainVisitor>) and make all resources extend that and let the user pass in a corresponding visitor and handle the actual type that's hidden by the polymorphism.

[berezovskyi]

But how would we instantiate that class? We get RDF, then we need to call a ctor with reflection and only after we can call the visitor method. If we figure out the perfect class to instantiate, what's the purpose of the visitor pattern? Otherwise, how would one add their implementation if we instantiate some very general class like OslcRdfResource or something?

[sgarfinkel]

I suppose this is a problem that's more applicable to the client @berezovskyi.

I'll open another issue with this if I encounter it