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

New work item: crate r2c2_term #6

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .github/CODEOWNER
Original file line number Diff line number Diff line change
Expand Up @@ -9,5 +9,8 @@
# Owners of the /dummy work-item
/dummy @pchampin @Tpt # ...

# Owners of the /term work-item
/term @pchampin # anyone else welcome, of course

# Owners of another work item
# ...
1 change: 1 addition & 0 deletions Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@

members = [
"dummy",
"term",
]
resolver = "3"

Expand Down
14 changes: 14 additions & 0 deletions term/Cargo.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
[package]
name = "r2c2_term"
version.workspace = true
authors.workspace = true
edition.workspace = true
repository.workspace = true
readme.workspace = true
license-file.workspace = true
keywords.workspace = true

[dependencies]

[lints]
workspace = true
10 changes: 10 additions & 0 deletions term/src/lib.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
//! TODO
//! One POSSIBLE way forward is to
//! 1. define or import simple wrapper types for building blocks
//! (IRIs, language tags...)
//! 2. define traits for different kinds of terms
//! (Subject, Predicate, Object, GraphName)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Perfect!

//! but the final design may be different.

#[cfg(test)]
mod test {}