Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disjoint polymorphic object parameter ranges #27

Open
TGNThump opened this issue Jul 19, 2020 · 2 comments
Open

Disjoint polymorphic object parameter ranges #27

TGNThump opened this issue Jul 19, 2020 · 2 comments
Labels

Comments

@TGNThump
Copy link

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.

@TGNThump TGNThump changed the title Polymorphic object parameter ranges Disjoint polymorphic object parameter ranges Jul 19, 2020
@ledsoft
Copy link
Contributor

ledsoft commented Jul 20, 2020

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
Copy link
Contributor

ledsoft commented Jul 22, 2020

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants