Use a proper RDF library for export

[JohannesLipp]

We currently build the export ourselves via string operations (cf. https://github.com/Semantic-Society/Neologism/blob/main/app/api/server/helper.ts), but a proper RDF library would improve this.

Possible libraries could be: https://rdf.js.org/ or https://www.npmjs.com/package/rdf or even https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries

[JohannesLipp]

This also closes #139

[alihussainiam]

N3.js seems suitable for use where we can extend and reuse the N3codec in repo

[JohannesLipp]

Decisions from today:

1. Move the export functionality back to the frontend
2. Replace the DB schema with native RDF/turtle. This also touches the publishing feature
3. Synchronize the RDF/turtle contents whenever required

[alihussainiam]

@JohannesLipp There remains a distinction to be made regarding the 2. point.

• Schema change meaning saving string ttl to db so that it could be efficiently downloaded w/o the need of execution of rdf serialize func on every time the download btn is clicked.
• But as of now we execute serialize func twice one on download and one on publishing buttons. Do we need both?
• Assuming the downloaded ttl is the one that has been published before and could be empty in case publish func was never executed once. Then we can remove the serialize exec on download and only do the fetch func from the db. Please confirm
• Above assumption will totally eradicate the need for an added route layer which is giving in the server log some warnings, because both the routes func is handled on front and with the only need of meteor methods will be additional to save in db

Decisions from today:

1. Move the export functionality back to the frontend
2. Replace the DB schema with native RDF/turtle. This also touches the publishing feature
3. Synchronize the RDF/turtle contents whenever required

[JohannesLipp]

@JohannesLipp There remains a distinction to be made regarding the 2. point.

• Schema change meaning saving string ttl to db so that it could be efficiently downloaded w/o the need of execution of rdf serialize func on every time the download btn is clicked.
• But as of now we execute serialize func twice one on download and one on publishing buttons. Do we need both?
• Assuming the downloaded ttl is the one that has been published before and could be empty in case publish func was never executed once. Then we can remove the serialize exec on download and only do the fetch func from the db. Please confirm
• Above assumption will totally eradicate the need for an added route layer which is giving in the server log some warnings, because both the routes func is handled on front and with the only need of meteor methods will be additional to save in db

Decisions from today:

1. Move the export functionality back to the frontend
2. Replace the DB schema with native RDF/turtle. This also touches the publishing feature
3. Synchronize the RDF/turtle contents whenever required

Result from today: Both buttons serialize the latest version.