kit-data-manager / kit-data-manager/ro-crate-java

Inconsistent use of set* and add*, especially in FileEntityBuilder

Open
#242 1 comment 0 reactions 0 assignees View on GitHub
invalid
Dominant language
Java
Stars
5
Forks
4
PR merge metrics
No merged PRs in 30d

Description

As mentioned in #216 there is the need to document purpose and differences of add* and set* in general. While the actual purpose seems to be clear on the semantic level, it's almost impossible to estimate the effect of a set* or add* call without deeper knowledge of the code. Let's take the following example:

```java
FileEntity file = new FileEntity.FileEntityBuilder()
.setId("survey-responses-2019.csv")
.addProperty("name", "Survey responses")
.addType("rdfs:Property")
.setLicense(new ContextualEntity.ContextualEntityBuilder().setId("licenseId").addProperty("name", "LicenseName").build())
.addProperty("contentSize", "26452")
.addProperty("encodingFormat", jsonNode)
.setLocation("http://example.com")
.build()
```

* **setId** - Compared to other calls it should do the same as addProperty('@id', id), but holds id different than other properties, such that addProperty('@id', '123') would not work (and may even cause errors). Furthermore, if the id was already set, the call does nothing, such that overwriting an id is not foreseen (which is somehow fine).
* **addProperty** - Should be better called setProperty(key, value), as previously added properties with the same name are overwritten. Thus, array values can only be set via addProperty(String, JsonNode). Therefore, one could think of either renaming addProperty to setProperty or changing its behaviour (see next point)
* **addType** - Actually does what an add-method is supposed to do. At the first call it initializes a HashMap and adds the provided value, while subsequent calls add additional values to the HashMap. So basically the behaviour expected also for addProperty.
* **setLicense** - One of the most confusing calls. In both cases, it internally calls addIdProperty("license", id). If you call it with a string argument, the value is assumed to be the license id and is directly used. If called with a ContextualEntity argument, getId() is used as license id, while the rest is omitted. Thus, the ContextualEntity of the license has to be added separately to the crate afterwards.
* **setLocation** - Probably the most confusing call as there are more internal possibilities of what may happen. If called with an URI, the argument is set as id. If id was set before, the call is ignored. If called with a path and the id was not set before, the filename is used as id and path as location. If id was set before, path is only used as location without changing the id. If path is null, nothing is done (unless setLocationWithExceptions is used) and if path points to an non existing file, everything is fine until the crate is written and an exception is thrown.

For the moment, I just wanted to have these points documented for further discussions. I also have the impression, that for other entity builders the situation is much clearer (and mostly limited on the builder-level to set* for single values), but a consistent behaviour would be desirable.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the FileEntityBuilder methods named in the issue, then compare add* and set* behavior in the other entity builders. Document the observed purposes and differences, including the examples for setId, addProperty, addType, setLicense, and setLocation; the issue does not name a documentation file or test.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.