Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language vs tool features #4

Open
dachafra opened this issue Oct 21, 2020 · 2 comments
Open

Language vs tool features #4

dachafra opened this issue Oct 21, 2020 · 2 comments
Labels
question Further information is requested validation

Comments

@dachafra
Copy link
Member

issue: Should we, and if so, how do we make a distinction between language and tool features?

suggestion: Survival of the fittest?

@dachafra dachafra added question Further information is requested validation labels Oct 21, 2020
@VladimirAlexiev
Copy link

Modularization of the whole conversion process is a great idea. so that teams can innovate in specific areas without having to implement complete converters from scratch.

Draft list of modules:

  • input parser
  • input reader with streaming (batching, chunking)
  • transformation parser
  • transformation engine that applies all relevant maps on a chunk of input
  • function evaluator
  • output constructor (as memory model of one chunk)
  • output serializers to different formats
  • output writers to file or different storages

@dachafra
Copy link
Member Author

Let's transfer to the best-practices repo, although IMO in languages should be an agreement, while optimizations and other techniques are part of each implementation/engine and related use-cases

@dachafra dachafra transferred this issue from kg-construct/mapping-challenges Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested validation
Projects
None yet
Development

No branches or pull requests

2 participants