RDF1.2 triple terms and RDF Messages types

[pietercolpaert]

We should probably add the concept of a Triple Term here as in RF1.2, as well as the concept for an RDF Message

[zozlak]

Triple Terms are covered by the RdfInterface since ever (see the QuadInterface which implements the TermInterface and uses TermInterface as a subject and object). Handling them (and impossibility to do it in the EasyRdf) was one of the main drivers for the RdfInterface creation.

As far as I can see an RDF Message is defined as a Dataset which already have. On the parsing/serialization side some design decisions are needed though. As for now the RdfInterface parsing/serialization uses quads iterator to pass data around. Two solutions come quickly to my mind:

• Implementation of a Quinq. Which is used only for parsing/serializing (we don't need it in datasets) and contains also a message unique identifier (so conceptually very similar to the way you added it to the hardf).
  • It's a good question what Dataset should do with a Quinq? Require converting it to a Quad (which can be a part of the Quinq API and will go down to dropping the message id)? Or maybe accepting and silently converting it to a Quad? Or maybe noting down a first Quinq message id and throwing an error when a Quinq with other message id is passed? Or maybe noting down a first Quinq message id and silently skipping Quinqs with a different message id?
  • It's a good question if Quinq should be comparable. The uniqueness of a message id can be only assured in a (narrow) context of parsing a given message stream but not globally and with the Quinq class approach we allow it to leave globally. So how explicit we should be about message id uniqueness limitation in the Quinq API?
• Implementation of a dedicated message stream parsing/serializing APIs which instead of Quad iterators would emit/take Dataset iterators. This would allow to keep identification of messages internal to a parser/serializer. And while using the current Quads`-oriented API:
  • The SerializerInterface::serialize() and SerializerInterface::serializeStream()can take an additional optional parameterbool $message = falsewhich will emit an RDF message indication in an output before writing passedQuad`s.
  • I would keep ParserInterface::parse() and ParserInterface::parseStream() as they are and leave the configuration of messages handling (should an error be thrown or should the division into messages be silently skippeed) up to the parser creation/confguration (which is not covered by the RdfInterface).

What are your thoughts here? (I have my own bets but I will reveal them later, when I sleep over with it).

[pietercolpaert]

I would certainly not go for a quing as that’s also not defined in RDF or RDF Messages. The messageCounter is internal to the parser as a way to keep messages themself also streaming.

Happy to accept a dedicated message stream parsing /writing APIs

[zozlak]

We're betting on the same horse then. I will try my best to prepare a pull request this month (not that it's that much work, it's just I don't have much time to invest in it).

[zozlak]

What do you think about #22?

[zozlak]

A friendly ping @pietercolpaert

[zozlak]

As I saw you have just done some work in the hardf repo @pietercolpaert - could you please take a look at the #22