kit-data-manager / inclde Goto Github PK

The updateEvent is currently more of a hack for local tests, and therefore not shown in the readme. You can find details in the automatically generated readme of the inclde-editor component. Currently, it is thrown on redraw of the component, which is not exactly what we need.

Please use a compact, or expanded format and do not serialize blank node ids.

I recommend to implemented a round-tour test, to check if the serialized graph is isomorphic to the one in memory.

Overall, I like what you do and the idea of it. It has potential if one can link a reference graph for the completion suggestions.

One will want to adjust colors and the look to a certain degree.

Make a concept that makes styling easy, using the different possibilities:

• CSS variables
• slots
• CSS ::part etc
• ...

Other possible evaluations:

• the use of slots to exchange property rendering without modifying the code

Resources:

• https://stenciljs.com/docs/styling

Note: Some of these are long-term tasks with low priority.

The data is currently a flattened JSON-LD document (a JS array), and we can not exchange it easily. This would be desirable to be more flexible with maintenance, but is not of urgent importance.

The autocomplete feature will likely experience requests:

• more implementations, maybe on configuration basis rather than constant implementations (due to being very specialized)
• more configuration, e.g. restrictions (shacl?) and other kinds of filters or extensions

What first comes to mind:

• APIs/interfaces for exchangeable implementations
• An implementation wrapping the structure/autocomplete as-is. The access methods must replace the util functions used to access the data. Instead of an index, we should consider using the @id attribute and how to handle the problems this approach will experience (ill-formed documents).

Benefits:

• easier to add new features and fix bugs without introducing new bugs
• makes access better testable, as we move shared state management from multiple components into a central place

The compaction of the output does not work due to some error in the library we use (jsonld). The issue is known and has to be worked around, probably with a custom document loader implementation working around http/s inconsistencies.

In this context, it should also be double-checked that we do not accidentally remove information by only returning graph content.

It may happen the user associates these buttons only with the selected elements. We could use some better placement or better CSS to associate it with the document as a whole.

Example: Adding a schema.org/Text to a schema.org/name array, results in:

name: [ {"@id": "asdf" } ]

Instead, the user should have the possibility to make it a direct value, like this:

name: [ {"@value": "asdf" } ]

Workaround? Using the JSON primitives results in this, which is unknown if it is valid:

name: [ "asdf" ]

In any case, it should be clear to the user how to do it properly.

Or in other words: The assistants for creating relations and nodes always want to have an ID for a type (which is not a JSON primitive). But in some cases it means we need primitives, which needs to be resolved.

• research: check if name: [ "asdf" ] is valid, which should help to evaluate an appropriate solution
• find an elegant solution for those "primitives"

Feeding the component with its output might help to detect errors. We can do this manually, but we can also try to implement this as an automated test. I am unsure if this will work with all the shadow DOMs, but it is worth a try.