You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to propose allowing additional properties by changing additionalProperties seen below to true. The purpose is to allow top-level attributes for simpler round-tripping into databases. Keeping the graph attribute tightly controlled makes a lot of sense for interoperability but allowing other top-level attributes to support easier record mgmt would make life easier for me and hopefully others when working with JGF in specific applications.
Expectation is that these additional properties would be completely ignorable when reading the JGF file in a different application - e.g. graph specific metadata should still be in graph.metadata object, application specific metadata would be the additional top-level attributes.
Related to this, I'm attempting to extend the schema to specify a description of how my graph will work. For example, I want to specify that nodes must take one of an enumerated set of strings as their name. However, the use of additionalProperties as false everywhere in the specification means that it cannot be extended at all. A balance needs to be found between tight control versus the ability to extend.
@grahamwhiteuk I'd enjoy reviewing the design decisions with you more interactively. I'm happy to share my contact details - William dot s dot hayes at gmail dot com
Are you talking about all additionalProperties: false or just the top-level?
@wshayes can I say what fantastic response, it's great to see such a welcoming approach and willingness for open conversation. I'll ping you an email.
Very briefly though, I'm starting to see some of the difficult decisions that need to be made here and I don't think there's an ideal approach but might be worth a quick chat to check.
I'd like to propose allowing additional properties by changing
additionalProperties
seen below totrue
. The purpose is to allow top-level attributes for simpler round-tripping into databases. Keeping thegraph
attribute tightly controlled makes a lot of sense for interoperability but allowing other top-level attributes to support easier record mgmt would make life easier for me and hopefully others when working with JGF in specific applications.Expectation is that these additional properties would be completely ignorable when reading the JGF file in a different application - e.g. graph specific metadata should still be in graph.metadata object, application specific metadata would be the additional top-level attributes.
This would be a semantic versioning MINOR change.
The text was updated successfully, but these errors were encountered: