next steps for graphql-schema-org

xmnlab commented 5 years ago

hey everyone, I want to discuss the next steps for this project.

schema.org is very flexible and graphql has some limitations such as:

schema.org author field could accept: Person | [Person!] | Organization | [Organization!] | String | [String!]
graphql union type doesn't support mixing objects and scalar/primitive types eg: String | Person or Person | [Person!]

schema.org is very flexible it allow String or List for any field (https://schema.org/docs/datamodel.html)

regarding this scenario I am proposing here to define each field as a list of a union type, eg:

union author = Person | Organization
type Dataset {
  author: [author]
}

so the responsibility of add one or more fields would be inside the client/frontend

it could be hard inside the resolver select what type correspond to each field/object so also maybe would be good to add some discriminator on union input types but maybe it could addressed in a new issue. locally in my experiments I created a MetaType and add that into each type eg:

type MetaType {
  typename: String
  // metadata could be used in the future also for other metadata such as `minvalue` as SHACL does, but it is not part of schema.org scope 
}

type Dataset {
  author: [author]
  _meta: MetaType
}

any thoughts?

xmnlab commented 5 years ago

regarding MetaType, probably for now just forcing __typename should be enough

brysgo commented 5 years ago

What is the added benefit of MetaType?

xmnlab commented 5 years ago

MetaType could store data that will enrich information about the type, like SHACL does. but maybe it is not something to address inside graphql-schema-org. and maybe if anyone want to add that ... it probably could be added in the implementation time.

so objectively, my proposal for a next step is just:

create union types, and;
use GraphQLList for each field, except for identifier (probably doesn't make sense a object with a list for identifiers). ex:

union author = Person | Organization

Dataset {
  identifier: String
  author: [author]
}

In an implementation side, the resolve could receive __typename or use ids with type name inside (e.g. Dataset/1). So the union types would work with no problem.

xmnlab commented 5 years ago

for union for input type I am investigating https://www.npmjs.com/package/graphql-union-input-type ... but I don't have any feedback yet.

xmnlab commented 5 years ago

I have some initial example doing that here: https://github.com/Quansight/jupyterlab-metadata-service/tree/type-and-id-refactoring/backend/jupyterlab_metadata_service_server/src/schemas

where I have split that into typedefs and input

I would be very happy to create a PR here with this approach :)

let me know your thoughts

webmasterkai commented 5 years ago

Whatever you think is good with me. I haven't had enough time to work on this recently.

xmnlab commented 5 years ago

awesome! thanks .. I will work on that!

cape-io / graphql-schema-org

next steps for graphql-schema-org #10