karelklima / ldkit Goto Github PK

Consider supporting language filtering on SPARQL level.

For example, for schema:

const Person = {
  "@type": schema.Person,
  name: {
    "@id": schema.name,
    "@language": "cs"
  }
};

When querying, the SPARQL query would filter only values with cs language for the schema:name property.

TODO:

• Upgrade Deno STD
• Replace esm.sh imports with npm: imports
• Upgrade dnt script to use the latest version
• Upgrade all dependencies to use the latest versions

It should be possible to pass a graph IRI to a resource context, effectively restricting all SPARQL queries to the particular graph.

This is useful for focusing resources / queries over a particular graph / context in a database.

For additional developer experience, LDkit should allow for the following:

• Matching of entities based on a partial entity, e.g. lens.match({ name: "Abc"});
• Working with huge arrays, e.g. lens.update({ $id, prop: { $add: "value"; });

This may require to extend LDkit language significantly. An alternative approach would be to use a proxy and translate actions on objects to SPARQL UPDATE queries, e.g. res.property.push("value") and then res.update(property) would yield the same result.

Consider using MongoDB language as an inspiration.

LDkit could support collections for greater benefits of developers.

Prerequisites:

• Standardized collection format
• Support for collections within SPARQL query

The referenced bindings factory comes with Immutable.js package, which is huge. Consider replacing it with custom implementation.

Include:

• Basic principles
• Shortcuts
• Simple properties
• Array / non-array properties
• Multilang properties
• Subschemas
• Schema composition and reusability

It should be possible to configure custom logger, and perhaps override the default one, using some reasonable interface. It should be compatible with the most prominent logging solutions in both Deno and Node.

Update to newest version of libraries, switch to Deno if possible.

The interface should enable user to do more powerful queries, order results, and find specific resources more easily.

Prisma could be a good inspiration in what to accomplish:

const results = await prisma.post.findMany({
  skip: 200,
  take: 20,
  where: {
    email: {
      contains: 'Prisma',
    },
  },
  orderBy: {
    title: 'desc',
  },
})

Some SPARQL servers like Oxigraph which I am using do not support application/rdf+json in CONSTRUCT/DESCRIBE queries. I currently convert text/turtle to json manually in a custom fetch function.
What would be the best way ti support this?

Namespaces are referenced through namespaces/mod.js internally, which may be an issue for tree shaking (confirmed - ParcelJS). Namespaces should be referenced directly within the library.

Currently the schema requires the user to have a type, which is fine for main entities, but may be a problem for sub schemas or generally substructures in schema. Therefore it should be possible to define a schema and the data shape without the type.

For a schema to be valid, at least a type or one property must be defined.

Right now it is not straightforward to update arrays, users either need to provide the whole array as a replacement, or directly insert or delete quads. It is also not clear how this behavior works for subschemas.

The goal is to support array modification using $set, $add and $remove operators.

The array operations will only consider literals or IRIs, not complex objects, i.e. it should be possible to create connections between a schema and subschema entity, but the operation should not result in updating an entity in an array. That would be confusing and unwanted.

Example:

Persons.update({
  $id: "http://some/person",
  friends: {
    $add: ["http://second/person"],
    $remove: ["http://third/person"]
  }
})

Related work: #48

Improve LDkit performance by allowing some properties to be lazy loaded, so that the user has to await them before being used.

Considerations:

• optional / required - the lazy properties would have to be optional, does not matter whether if it is an array or not
• allow for simple properties and subschemas - useful for huge arrays
• Decoder / Encoder would have to be reworked significantly to allow injection of functions to resulting data

It should be possible to specify that a property in schema is @inversed, reversing the triple pattern matching (s p o -> o p s). Useful for querying data with incoming links.

Options:

• resource lens / lens
• data interface
• entity repository
• executor / executive
• bridge
• adapter

Alternative options:

• data link
• agent
• broker
• access point
• connection

LDkit currently loads all RDF types of main entities in schemas, which has a performance impact, especially on the query engine / SPARQL endpoint.

TODO:

1. Remove autoloading of entity types
2. Figure out a way how to replace this feature explicitly, e.g. using a custom method in a schema.

Use case: authorization, custom headers.

Currently, it is possible to set a language within the Context, which has its negatives. As an alternative, consider instead adding support to filter certain fields by language using the find method and the where specification.

Currently the typings of results coming from lens are resolved as SchemaInterface<{ property: ... }> and developers can see this wrapped schema instead of the actual objects and properties. Provide a better type resolution to "unwrap" the types.

https://fresh.deno.dev

Improve DX of schema specification using const type parameters: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#const-type-parameters

This could be useful for creating a schema so that the as const is not needed, and may perhaps be replaced with a wrapper function.

TODO:

• dark mode
• responsive design
• switch steps 1 and 2 on homepage

At the moment it is possible to specify limit of entities to query and pagination must be done in client side. Users should be able to specify offset and limit when querying for entities.

The AsyncIterator dependency is based on Node EventEmitter, which cannot be used in browser without polyfill. Since the dependency is not heavily used, it should be removed in favor of regular async iteration.

Include SPARQL endpoint requirements and a list of supported software (e.g. Virtuoso, GraphDB).

Multilanguage arrays may be confusing and not really a relevant feature, consider dropping support. Not sure what is the use case for that anyway, besides perhaps cleaning up messy data.

The SPARQL builder dependency comes with a lot of data, including a separate DataFactory and vocabularies. Consider implementing a custom solution.

Creating context and passing it to a resource

While it is possible to replace QueryBuilder component in LDkit during runtime, it is not straightforward and the API for this is not documented. Users should be able to define a custom QueryBuilder so that they can modify SPARQL queries or perhaps implement custom query languages more easily if needed.