New work item: crate r2c2_term

[pchampin]

The idea of this crate is to be the first component of the "common API".

It would focus on RDF terms, and would provide

• lightweight wrapper types (either defined or imported from utility crates) to guarantee the syntactic validity of some building blocks (IRI, language tags...)
• traits for different term types (Subject, Predicate, Object, GraphName)
• possibly other smaller traits that would be shared by those above (something like MaybeIri, MaybeLiteral...)

Also, since triple terms will force use to define a notion of Triple, it might make sense to also define Quad in this crate, although this stretches the scope of the crate a little bit. Should we name it instead r2c2_term_statement, which is more accurate, but a little verbose...

[Tpt]

Thank you! It's definitely the most important goal of our CG but sadly likely one of the trickiest to get right. We need to find a compromise between ease of use and versatility and I fear it won't be easy.

[Tpt]

This is imho going a bit too much into the "how" direction. It does not sound obvious that these should be traits and not enums.

[pchampin]

I'll argue in favor of traits here:

What I aim is to avoid as much data transformation as possible when communicating between two implementations. That's why I try to favor lighweight wrapper types, and traits.

Imagine I want to consume some triples produced by oxttl to canonicalize them with sohpia_c14n. (I'll focus on subjects but of course the same would apply to predicates and objects). If Subject was an enum, I would have to transform the subjects produced by oxttl into that enum. And then sophia_c14n would have to transform this enum again into its own internal representation.

If OTOH Subject is a trait, which the types of oxttl implement, and which sophia_c14n accepts as input, then the data produced by oxttl can be passed directly to sophia_c14n, which then will transform it directly into its own internal representation. That's one transformation less.

[Tpt]

On the other side having an enum makes manipulation easier. I tend to think this is a compromise to be done when we know more about how we represent IRIs/blank nodes/... and should not be set in stone at the beginning of this work item.

[pchampin]

I'm happy to defer this discussion, the goal was not to set anything in stone. I've just pushed a commit to clarify that the proposed design was just an example.

[Tpt]

Thank you! Perfect!

[pchampin]

Thank you! It's definitely the most important goal of our CG but sadly likely one of the trickiest to get right. We need to find a compromise between ease of use and versatility and I fear it won't be easy.

Agreed. I tried to not be too specific in the PR, but on the other hand, keeping things too abstract make them without substance. I don't think it would make sense to agree an a very abstract work-item if we don't have some agreement on what it will contain.

But of course, we don't need to figure out all the details up-front.

[Tpt]

I don't think it would make sense to agree an a very abstract work-item if we don't have some agreement on what it will contain.

Yes! What about something in the line of "It would provide types to encode and manipulate RDF concepts like IRI, blank node, literal, term and triple", making the scope clear while leaving the struct vs trait undefined?

Should we name it instead r2c2_term_statement, which is more accurate, but a little verbose...

I would tend to prefer r2c2_model in the line of RDF/JS DataModel or r2c2_concepts in the line of RDF concepts & abstract syntax. I agree that Quad is likely in scope.

[pchampin]

Re. terminology:

• I consider, maybe wrongly, that "type" encompasses "struct" and "enum" (as well as atomic types), but not "trait". I believe this is consistent with the use of the use of the keyword type in Rust, but I can see how traits are a kind of (higher level) types as well.

• I would expect a crate named r2c2_model or r2c2_concepts to also include the notion of Graph and Datatype, which is not the goal here. That's why I didn't go for that. r2c2_foundation ?