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

rdf2hdt issues #53

Closed
LaurensRietveld opened this issue Jan 25, 2017 · 10 comments
Closed

rdf2hdt issues #53

LaurensRietveld opened this issue Jan 25, 2017 · 10 comments

Comments

@LaurensRietveld
Copy link
Member

LaurensRietveld commented Jan 25, 2017

There are a few issues with the rdf2hdt command:

  • It does not always print to stdout (using rdf2hdt file.hdt -).
  • The built-in N-Triples serializer works, but when the Raptor serializer is included it does not.
  • Do we want raptor as a serializer anyway? (considering that the parser lib was changed to serd Remove built-in N-Triples parser/serializer #31)
@RubenVerborgh
Copy link
Member

Side note: Serd replaced the default N-Triples parser; raptor might still be useful for XML (not for me though 😊). But if the internal N-Triples writer is good, raptor can go.

@LaurensRietveld
Copy link
Member Author

The internal ntriples writer works fine for me so far. I'll use it a bit more, and if there are no problems I'll put in a PR to remove raptor

@LaurensRietveld
Copy link
Member Author

Just to verify: you're talking about raptor still being useful as parser, but not as serializer right? I.e., if the internal ntriple serializer is sufficient, we're going to remove the raptor dep and only support ntriple as serialization output

@RubenVerborgh
Copy link
Member

Indeed. However, we should double-check escaping and special characters (because this is where the built-in parser was horribly broken).

@drobilla
Copy link
Contributor

drobilla commented Jul 9, 2017

I implemented a Serd serializer in #75

This should fix any escaping/etc issues that might be hanging around and also support abbreviated Turtle output with similar performance (Serd does this in constant space).

I have no stance on dropping the internal NTriples serializer if you don't mind a mandatory dependency on Serd, though less code is always good. Dropping Raptor entirely would mean the loss of XML support, though, since Serd does not and will never support XML.

@RubenVerborgh
Copy link
Member

RubenVerborgh commented Jul 9, 2017

I think Serd is the way forward. We should drop all Raptor support for everything besides XML, so we don't have to maintain two parsers for the same things.

@drobilla Could you do an official release of Serd 0.27.1, which is needed to compile this?

@RubenVerborgh
Copy link
Member

Ported this issue to #76 and #77.

@drobilla
Copy link
Contributor

drobilla commented Jul 9, 2017

That'd be 0.28.0 (I do the even number stable release thing).

Sure, I can do so shortly, but unfortunately just added new API for this once again so I need to go through some things before releasing and can't do it this instant. Both reading and writings in hdt-cpp works well now though without any hacks, so I think it's fine. I'll release this week some time.

@RubenVerborgh
Copy link
Member

Perfect, then we can release a new hdt-cpp when 0.28.0 is available.

@drobilla
Copy link
Contributor

http://drobilla.net/2017/07/21/serd-0-28-0.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants