kit-data-manager / ro-crate-java Goto Github PK
View Code? Open in Web Editor NEWJava library to create and modify RO-Crates.
Home Page: https://kit-data-manager.github.io/webpage/ro-crate-java/
License: Apache License 2.0
Java library to create and modify RO-Crates.
Home Page: https://kit-data-manager.github.io/webpage/ro-crate-java/
License: Apache License 2.0
According to the spec (6.2 Direct properties of the Root Data Entity), the root data entity MUST have datePublished and license properties. These properties are currently not required in the the RoCrateBuilder. The other required properties (those that are not auto-generated) are passed as parameters through the RoCrateBuilder constructor. I suggest we do the same for datePublished and license.
Issue taken over from the old repository
While testing the library, HTML previews are build using 'ro-crate-html-js' by default. If this dependency is not available, some tests will fail without detailed information.
It should be clear in README.md that this dependency (including Node.js and NPM) are required.
This is a really small issue, but if you create an empty RO Crate with the builder and then print the JSON metadata
RoCrate crate = new RoCrate.RoCrateBuilder().build();
System.out.println(crate.getJsonMetadata());
You get this:
{
"@context":"https://w3id.org/ro/crate/1.1/context",
"@graph":[
{
"@id":"./",
"@type":"Dataset"
},
{
"about":{
"@id":"./"
},
"conformsTo":{
"@id":"https://w3id.org/ro/crate/1.1"
},
"@id":"ro-crate-metadata.json",
"@type":"CreativeWork"
}
]
}
This seems to be the minium valid RO Crate.
But if you do the same with the RoCrate constructor:
RoCrate crate = new RoCrate();
System.out.println(crate.getJsonMetadata());
You get this:
{
"@context":"https://w3id.org/ro/crate/1.1/context",
"@graph":[
null,
null
]
}
Shouldn't they be the same?
I am attempting to send RoCrates over HTTP and AMQP, this appears to require serializing and deserializing RoCrates to JSON /
Byte array.
I have attempted to use FasterXML Jackson but was unable to use successfully readValue / convertValue to create RoCrate objects (see error below).
Is there another way to serializing and deserializing RoCrates to be transmitted over the network.
Stuart
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of edu.kit.datamanager.ro_crate.entities.data.RootDataEntity
(no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
at [Source: (String)"{"rootDataEntity":{"name":"Request","description":"74e0d9a7-f175-450d-8726-73c3d07579c0","@id":"./","@type":"Dataset","hasPart":[{"@id":"http://example.org/8447fd4d-fbb8-45cf-9c55-f590ed775eb0"},{"@id":"http://example.org/35f215f2-2aec-42a7-bea9-c01e31ed3dcb"}]},"jsonDescriptor":{"about":{"@id":"./"},"conformsTo":{"@id":"https://w3id.org/ro/crate/1.1"},"@id":"ro-crate-metadata.json","@type":"CreativeWork"},"untrackedFiles":[],"allDataEntities":[{"Answer to the Ultimate Question of Life, The Univ"[truncated 1097 chars]; line: 1, column: 20] (through reference chain: edu.kit.datamanager.ro_crate.RoCrate["rootDataEntity"])
There will be a new ROR schema available, probably end of this year. We should evaluate if we need to adjust our ROR mapper accordingly.
We use lists in many places, and I think in most of them a set would be the better solution. API changes will be possible here, though. So we have to be careful and deprecate old APIs.
There is no way to add to the the context without using the RoCrateBuilder (which is not possible when using the RoCrateReader).
There are probably more features missing, and the nicest fix IMO would be to extend the RoCrateBuilder to allow using an existing RoCrate as a template.
RoCrate crate = new RoCrate.RoCrateBuilder(existingCrate)[...]build();
build.gradle
it says group 'org.example'
. It should be changed, but I am not sure which parts exactly it will affect.edu.kit.crate
as the high level package name. Should we reconsider this to be e.g. edu.kit.ro_crate
? Or even edu.kit.datamanager.ro_crate
?It seems that provenance elements defined in the RO-Crate specification are not supported. Thus, it is not possible to describe the provenance of data, e.g., CreateAction, UpdateAction, used instruments etc.
AFAIK, the easiest way to delete a property by name from an entity is this one:
entity.setProperties(entity.getProperties().remove("property_name"));
I don't like that we have to work with JsonNodes to delete properties, maybe adding a very simple
void removeProperty(String key)
would be nicer? I think we would only need to add this to the AbstractEntity class.
The API is documented by examples and javadocs (the non-trivial-parts at least) and is pretty straight forward. But there is space for improvements, as far as I can see:
Parts of this are also interesting for users:
People should be able to use it more easily in their software, so we should have the pre-built library in a repository.
Version: As we have some minor open issues, I am considering staying with 1.0-SNAPSHOT or even 0.9 or something like that.
We can already add Urls and key-value pairs to the context, but there is no way to delete them from existing crates. (Also no way to read them besides raw JSON, but that's a different issue)
I propose adding these two functions to the RoCrate:
public void deleteUrlFromContext(String Url)
public void deleteValuePairFromContext(String key)
I am going to make a PR for this later today.
According to paragraph 7.2.1 (Encoding file paths) all file paths may be encoded. Currently, the library does not decode any URLs. This leads to a few errors while reading crates, especially while checking if files exist and when creating a DataEntity. There are probably a lot of places where this needs to be fixed
Note that all @id identifiers must be valid URI references, care must be taken to express
any relative paths using / separator, correct casing, and escape special characters like
space ( %20 ) and percent ( %25 ), for instance a File Data Entity from the Windows path
Results and Diagrams\almost-50%.png becomes "@id":
"Results%20and%20Diagrams/almost-50%25.png" in the RO-Crate JSON-LD.
You can do
crate.addDataEntity(new DataSetEntity.DataSetBuilder().setId("./").addProperty("not_root", true).build(), true);
which then leads to this JSON:
{
"@context":"https://w3id.org/ro/crate/1.1/context",
"@graph":[
{
"@id":"./",
"@type":"Dataset",
"hasPart":{
"@id":"./"
}
},
{
"about":{
"@id":"./"
},
"conformsTo":{
"@id":"https://w3id.org/ro/crate/1.1"
},
"@id":"ro-crate-metadata.json",
"@type":"CreativeWork"
},
{
"not_root":true,
"@id":"./",
"@type":"Dataset"
}
]
}
The same can happen if you use ro-crate-metadata.json
as Id. This should not be possible!
Note:
This is not yet part of the specification! What we do have already, is support for multiple "conformsTo" values, meaning multiple profiles being specified for a crate. Please remember, both are features of the 1.2-DRAFT specification and there is no guarantee they will make it into the final version.
If you have an urgent need, feel free to discuss further proceeding here. Code contributions are always welcome. What may implement at some point:
Resources:
First of all, thanks for the library!
Currently the library targets RO-Crate 1.1 and the current behaviour regarding the use of conformsTo
is implemented according to this:
https://www.researchobject.org/ro-crate/1.1/root-data-entity.html#finding-the-root-data-entity
if the conformsTo property is a URI that starts with https://w3id.org/ro/crate/
...
This is implemented here and expects to have a single object for conformsTo
with an @id
value:
In the proposed 1.2 draft the conformsTo
may be an array of such objects.
https://www.researchobject.org/ro-crate/1.2-DRAFT/profiles.html
It is valid for a crate to conform to multiple profiles, in which case conformsTo is an unordered array.
We try to use this multiple profile support of RO-Crate 1.2 in our project, so it would be great if you could support multiple conformsTo
values. Currently, it throws as error because the type.get("@id").asText()
will fail when type
is an array.
According to the specification, every Data Entity MUST be linked to the Root Data Entity:
Where files and folders are represented as Data Entities in the RO-Crate JSON-LD, these MUST be linked to, either directly or indirectly, from the Root Data Entity using the hasPart property.
Adding a Data Entity like this is valid according to the library:
crate.addDataEntity(new DataSetEntity.DataSetBuilder().setId("./some_file").build(), false);
Now at this point, the crate is not valid. If you add a DataSetEntity that has a hasPart
property linking to ./some_file
and the Root Data Entity has a hasPart
property linking to this DataSetEntity it would be valid again.
Reserved keywords cause warnings because of missing definition in context. Those keywords usually begin with "@", for details see the links.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.