Bug: When ingesting a File entity its @id gets a # suffix about ro-crate-py HOT 2 CLOSED

The spec says data entities MUST be linked from the root via hasPart; hasFile, OTOH, is only mentioned as a term imported from PCDM. When reading a crate, the library adds all items listed in hasPart as data entities, then assumes everything else ("test.csv", in this case) is a contextual entity. Since "test.csv" is not an absolute URI, it adds a # to turn it into a local id (this is done for all contextual entities).

To sum it up, I believe the library is behaving consistently with the spec here. I will close this and perhaps you can open an issue on the ro-crate repo if you think a spec update is necessary.

from ro-crate-py.

OK, my test case was wrong - I keep getting hasPart and hasFile mixed up. My mistake, sorry!

And yes, that is what the spec says. When I introduced the abstract repository classes from pcdm it was to allow a crate to contain a set of files with an abstract structure that does not necessarily reflect the directory structure - as exported from a database or repository. What this means is that we probably should have said that the pcdm classes are DataEntities that can be chained like Datasets/directories and that hasFile is equivalent to hasPath.

from ro-crate-py.