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

Disjoint polymorphic object parameter ranges #27

Open TGNThump opened 4 years ago

TGNThump commented 4 years ago

I'm not sure if a github issue is the best place to discuss this, so feel free to close this if you feel it's the wrong place for this discussion, but...

How would you recommend handling a property such as https://www.w3.org/TR/activitystreams-vocabulary/#dfn-url where the Range can be either an xsd:anyURI or a Link object, or https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attachment where the Range can be either Object or Link.

Many of the properties in ActivityStreams4J are defined as java.lang.Object for this reason, but this obviously reduces the amount of type information avaliable and therefore causes UnknownPropertyException.

Any suggestions would be greatly appreciated.

ledsoft commented 4 years ago

That's a good question. I'm not very familiar with activity streams, but given the said properties, I think it depends whether type information is available in the JSON-LD input. If it is (like Example 110 and 111 for the URL property definition), JB4JSON-LD should be able to determine correct actual Java type even if the target field type is Object. If type information is not available in the input, it is basically impossible to determine the actual target type and the library will attempt to use plain Object. Another problem could be determining whether to use OWLDataProperty or OWLObjectProperty if the value is either plain string (xsd:anyURI) or a Link object, but in that case, it should help to use OWLAnnotationProperty, which accepts both literal values and objects. However, that may not be suitable if OWL reasoning on storage level comes into play. But that would depend on your specific case.

ledsoft commented 4 years ago

On a second thought, a more generic solution which would most likely resolve the problem would be support for custom (de)serializers for fields/classes much like Jackson's @JsonDeserialize and JsonSerialize. That way, you would be able to easily override the default (de)serialization behavior.

I'll create an issue for it, but it may take a while to implement...