-
Notifications
You must be signed in to change notification settings - Fork 23
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
Literal as type #35
Literal as type #35
Conversation
The content of the variant Term::Literal() is turned into an own type. This way it should be easier for thrid party libraries to implement custom functionality for RDF-literals.
…iteral-as-type
New constructor for simple literals, i.e. literals with datatype `xsd:string`. Where suitable the new constructor is invoked.
I'm not sure exactly what problem you are trying to solve with the All I can see is additional verbosity due to the intermediate type. I can see a few interesting ideas:
but all of them could be implemented without the additional What am I missing? |
My intention is to seperate handling of the single RDF-terms (IRI, blank node, literal, variable) from an RDF-term that can be anything. In my opinion this makes it easier to reason about how a certain type of term is handled. Let me explain it for serialization. Assume a trait for serializing something conformant to NTriples: trait NtSerializable {
fn seriallize<W: io::Write>(&self, w: &mut W) -> io::Result<()>;
} This can be implemented for basic types like impl NtSerializable for Term {
fn serialize<W: io::Write>(&self, w: &mut W) -> io::Result<()> {
match self {
Iri(iri) => iri.serialize(w),
Literal(literal) => literal.serialize(w),
...
}
}
} Continuing this up to Another point I want to make is uniformity. As the same is already done for IRIs and blank nodes I thought it would just be consequent to do the same for literals (and maybe variables). Especially, as blank nodes are less complex as literals but already have an own type. In a broader scale the seperation of Applications will pick probably only a bunch of concrete crates from the On the other hand this would allow us to support external term implementations with existing sophia code, For example, use rio's terms directly in Furthermore, extensions of the RDF-standard could easily interoperate with the However, this is not the topic of this PR and should prabably be moved into an own issue. |
Ok, that is clearer, thanks. In the current design, I thought of the As I understand, you propose an approach where each subclass is defined as a separate type, and variants of the superclass enum are mere wrappers. I agree this is more regular, probably easier to understand, and possibly more idiomatic (see for example https://docs.rs/json/0.12.1/json/enum.JsonValue.html). If we go that way, though, I would prefer:
As for turning |
I'm happy to see that we came to an agreement, my intentions are exactly as you understand. Your preferred points are reasonable and I agree on them, too. As this PR starts to heavily conflict with #37 and the changes required differ more and more from my initial proposal I close this PR and will commit a new one when the serializer PR is merged. |
This PR contributes to #34 .
With this PR the contents of
Term::Literal
are extracted into a new typeLiteralData
. This should allow third-party authors to easier add specific behavior for RDF-literals, e.g. serialization.Furthermore, the calls to
n3()
has been reduced in the modified code (see #34).In addition, the function
Term::new_literal()
is added. A shortcut for creating simple literals, i.e. literals with datatypexsd:string
.