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
As of right now, rlay (server) and the rlay-ontology does support any functionality to restrict the schema of an ontology. For example: Only http:Connection can have ObjectPropertyAssertion of type http:requests. W3C provides SHACL for this use-case and GraphQL has it's own schema definition language.
But, rlay-client-lib with it's generated client supports some very basic way of setting fields and defaults, which are used when .assert and .create are called. It seems that this could be a good start to get schema validation sorted, at least for the client. The functionality could well be provided by a third-party library (research and dd has not been untertaken so far) and could then be implemented very quickly.
However, so far support for schema validation has not been a blocker in any way and it seems like a nice-to-have further down the road. So this, issue is just for documenting with lowest priority.
The text was updated successfully, but these errors were encountered:
As of right now,
rlay
(server) and therlay-ontology
does support any functionality to restrict the schema of an ontology. For example: Onlyhttp:Connection
can have ObjectPropertyAssertion of typehttp:requests
. W3C providesSHACL
for this use-case and GraphQL has it's own schema definition language.But,
rlay-client-lib
with it's generated client supports some very basic way of setting fields and defaults, which are used when.assert
and.create
are called. It seems that this could be a good start to get schema validation sorted, at least for the client. The functionality could well be provided by a third-party library (research and dd has not been untertaken so far) and could then be implemented very quickly.However, so far support for schema validation has not been a blocker in any way and it seems like a nice-to-have further down the road. So this, issue is just for documenting with lowest priority.
The text was updated successfully, but these errors were encountered: