Open dt-woods opened 4 months ago
Why is so much of the metadata removed from the Ref object?
For the import or communication with openLCA only the @type
and @id
fields are required to identify the referenced dataset, in most cases even only the @id
field because there is often only one type allowed (exceptions are calculation targets and process links). The other fields are just there to make these references human-readable and to display these metadata in user interfaces like the Collaboration Server.
The to_ref
method is automatically generated from the schema definition for different types and thus only includes some common metadata. The code generator could be extended to include more type specific metadata but I currently do not see a use-case because you already have the full object when calling to_ref
.
My use case is generating JSON-LD files to be read by openLCA. It sounds like the important info is in the auto-generated reference objects. I'm guessing openLCA can fill in the missing details once imported into the database.
On Wed, Feb 28, 2024, 02:57 Michael Srocka @.***> wrote:
Why is so much of the metadata removed from the Ref object?
For the import or communication with openLCA only the @type and @id fields are required to identify the referenced dataset, in most cases even only the @id field because there is often only one type allowed (exceptions are calculation targets and process links). The other fields are just there to make these references human-readable and to display these metadata in user interfaces like the Collaboration Server.
The to_ref method is automatically generated from the schema definition for different types and thus only includes some common metadata. The code generator could be extended to include more type specific metadata but I currently do not see a use-case because you already have the full object when calling to_ref.
— Reply to this email directly, view it on GitHub https://github.com/GreenDelta/olca-schema/issues/8#issuecomment-1968420837, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHCFB5JYEEZZMTKMLZVO63TYV3PNXAVCNFSM6AAAAABD456ANOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRYGQZDAOBTG4 . You are receiving this because you authored the thread.Message ID: @.***>
How important is the @context
tag in the JSON files?
I'm noticing that JSON files have this metadata when exported from openLCA (i.e., the value set to http://greendelta.github.io/olca-schema/context.jsonld), but it's not there when I use olca-schema to write to JSON-LD.
When examining the metadata in JSON-LD, the "reference" metadata is richer than that provider by this Pythonic schema's
to_ref
method conveniently provided with each root entity.For example, the JSON-LD information in a ProcessLink within a Product System includes a reference to an exchange, flow, process, and provider such as the following (copied and pasted after reading a JSON-LD file exported from openLCA v2):
This makes me think that I could query a process that I want and convert it to a Ref object to meet this metadata standard (after all, that's what the documentation says to do for the 'process' attribute for a ProcessLink). When I do so, this is what happens:
Where'd all the metadata go?
For clarity:
All this questioning is roused from the poor handling of product system creation (see olca-ipc Issue #31).