search

kbss-cvut / jb4jsonld

JSON-LD serialization and deserialization for Java REST services.
GNU Lesser General Public License v3.0
10 stars 3 forks source link

handle polymorfism in property ranges during deserialization #26

Closed cristianolongo closed 3 years ago

cristianolongo commented 4 years ago

I have a class C with a single-valued property p and a range constraint which restrict the range of p to a class D (this constraint is espressed as a subclass constraint assertion on C). D has two subclasses D' and D''. In my json file I has a property assertion stating that an individual of class C is linked to an individual which belongs to both classes D' and D'' (D'' is the same) via the property p. I would expect that the individual of class D' would be deserialized as individual of (the java class corresponding to) D, in light of the constraint on C. However an AmbiguousTargetTypeException is thrown as D' and D'' are detected as possible target candidates. See cz.cvut.kbss.jsonld.deserialization.util.TargetClassResolver, row 48.

Please let me know if a pull request to fix it as I would expect may be appropriate.

ledsoft commented 4 years ago

Hi, this behavior is intentional. JB4JSON-LD will try to find the most specific matching type and if there are multiple (D' and D'' in your case), the library cannot decide which one to use. Using the parent (D) is theoretically possible, but what if it is abstract, or an interface? In addition, if D is a concrete class, the JSON can contain attributes mapped by D' or D'' which in this case wouldn't match in D. I suppose a configuration parameter could be used to override the default behavior in favor of using the parent, with the risk of loosing some attributes. In that case, a PR would be welcome.

ledsoft commented 4 years ago

I think the planned support for custom (de)serializers would help in this case as well. See #28

cristianolongo commented 4 years ago

Honestlt It is quite common in the semantic web realm that a class has some subclasses not necessarily disjoint. So we have to think about a solution in which no exception is thrown in this case.

ledsoft commented 4 years ago

Fair enough. @psiotwo , what do you think?

psiotwo commented 4 years ago

but what if it is abstract, or an interface?

Good point. We can try to go higher in the hierarchy.

with the risk of loosing some attributes.

If D has unmapped properties, the additional D',D'' props should appear there.

I think it makes sense to support this parent resolution and a configuration parameter for using parents optimistically should be appropriate.

cristianolongo commented 4 years ago

In this case one expect an object of class D, so returning an individual of any of its subclasses D' or D'' is good enough.

ledsoft commented 3 years ago

Implemented in 0.8.2. Configured via the enableOptimisticTargetTypeResolution and preferSuperclass parameters. Feel free to check it out and reopen (or report a new issue) if there are any problems.