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

Nature / role of triples #150

Open
pchampin opened this issue Jan 23, 2025 · 3 comments
Open

Nature / role of triples #150

pchampin opened this issue Jan 23, 2025 · 3 comments

Comments

@pchampin
Copy link
Contributor

In RDF* and the CG's RDF-star report, there was only one kind of (RDF-star) triple, which were defined recursively.
Then, triples could play two different (non-exclusive) roles in a given RDF graph:

  • be asserted (i.e. being an element of the set of triples that is the graph)
  • be quoted (i.e. being used in the subject or object position of a triple (asserted of quoted) in the graph)

When we shifted the terminology from "quoted triple" to "triple term", we subtly changed our perspective. The different roles became different kinds. RDF-Concepts defines "triple" (element of a graph) and "triple terms" separately, with some oddities ("subject", "predicate" and "object" are used long before they are defined). Also, for Semantics, @franconi had the need to define an umbrella concept ("triple structure") to reunite the two.

I think I would prefer to go back to a single kind (triples), and two roles (asserted triple, and triple term). This would imply refactoring the definitions in RDF-Concepts, but would not be a huge change in the rest of the document. Apart from the definitions, most of the text can be read either way, IMO.

@niklasl
Copy link
Contributor

niklasl commented Jan 24, 2025

I support this. The triple and two different roles thereof is simpler than having two distinct terms sharing the exact same structure.

I think this is key: the same triple is either an element of the graph, meaning that it makes sense (a statement), whereas the triple used as an object denotes its possible sense (a proposition).

(This is simpler both conceptually and in implementation. It would also make it simpler to define symmetric and generalized RDF, which are currently missing their corresponding loosened triple terms, as @franconi pointed out.)

@afs
Copy link
Contributor

afs commented Jan 25, 2025

This would imply refactoring the definitions in RDF-Concepts

@pchampin -- could you sketch that out please? I'd like to see an outline to understand the full impact.

@pchampin pchampin added the needs discussion Proposed for discussion in an upcoming meeting label Jan 29, 2025
@w3cbot
Copy link

w3cbot commented Jan 30, 2025

This was discussed during the #rdf-star meeting on 30 January 2025.

View the transcript

Nature / role of triples 2

ktk: We'll time-box this discussion.

enrico: I'm sympathetic with the idea, but wonder what the impact is everywhere?
… We can explain this, but when we say "triple", what do we mean?
… We say triple terms are asserted, but that's sloppy.
… We should not change the notion of "triple".

pchampin: I would say we're not changing the notion of a triple. The only use was to be asserted in a graph.
… That's my mental model; now we need to be clearer when we talk about a triple where it is used.
… When I reviewed RDF Concepts, it didn't seem to need much change.
… The text talks about asserted triples. We need to be clear that a triple in a graph means that the triple is asserted.
… There is a discussion of "appears in the graph", which could be moved to concepts later.
… Most of the text should still work.

enrico: I think some one needs to be responsible for having a pass over the text to put it in order.

tl: We need a name for the triple term we've introduced.
… As far as I say, the spec uses "triple" for the abstract thing, and "statement" for a triple which is asserted.

gkellogg: worries about breaking a concept by over-simplifying it.

pchampin: I agree, a statement is something you make by putting a triple in a graph, it's not the triple itself.

<AndyS> +1 to text outside definitions saying "triple" can be clear by context and that's OK.

pchampin: I don't think we change the terminology, it's more how we introduce the terminology.
… We present them as two different kinds of things; I propose we go back to the CG report and define a triple as something abstract.
… When the context is not enough, we can call it "asserted", when it's used as the object, it's a "triple term".
… Most of text should work as is.

<niklasl> +1 to pchampin

ora: I tend to agree. Are we fixing something that isn't really broken.

enrico: We keep using "triple term" and "triple", and this could fix it.
… The notion of a triple being in a graph is improved by the definition of "appears in a graph".

Souri: Having "asserted triple" and "triple term" makes things clearer.
… It's when a triple is in a graph, or appears as a term.
… If we say triple, it would normally mean "asserted triple". The "asserted" could be added to clarify.

<niklasl> +1 to Souri, this clarifies the two roles that a triple may have (two usages).

ora: You're suggesting we say "asserted triple" only when it's not clear from the context.

tl: I talked about asserted triples in the context of rdf:states. It has become common place in the WG, but I don't know that it is outside.
… Also, what happened to "statement", no one mentions the term any longer.

<pchampin> https://www.w3.org/TR/rdf12-concepts/#resources-and-statements "This statement corresponding to an RDF triple is known as an RDF statement."

<pchampin> The statement *corresponds* to the triple, it *is* not the triple.

ora: I think that "triple" has a lot of history; if you're worried that "asserted triple" is not in the spec, we can add it.

enrico: We had a long discussion about the use of "statement". We were convinced from looking at the spec that "statement" is for asserted triple.
… The current spec says that asserted triples are statements.

AndyS: I went through semantics, and the word "statement" comes up 12 times.

<AndyS> https://www.w3.org/TR/rdf12-semantics/#extensions

AndyS: The first mention is "RDF statements of the form ...", and shows a triple.

niklasl: I agree with Enrico. We will need some work on the text to clarify things.
… Regarding this issue (replacing triple term with triple), I think it makes the specs simpler.

<james> are statements also propositions?

niklasl: I'm not too worried about this. I think this formally makes things simpler.

ora: What are we fixing here? Most of the language is already clear.

pchampin: We need to fix the definnitions of "triple" and "triple terms" in concepts. Currently, they are two different things; they need to be the same thing with different roles.
… That just affects the text where they are defined. I volunteered to make a PR for this.

ora: do we need the resolution?

ktk: I think we need it to limit future discussion.

<gb> Issue 150 Nature / role of triples (by pchampin) [needs discussion]

<gkellogg> +1

<pchampin> PROPOSAL: rephrase the definitions of triple and triple terms in RDF concepts according to w3c/rdf-concepts#150

<fsasaki> +1

<niklasl> +1

<pchampin> +1

<ora> +1

<gkellogg> +1

<tl> +1

<doerthe> +1

<AndyS> +1

<TallTed> +1

<gtw> +1

<eBremer> +1

<Souri> +1

<james> +1

<ktk> +1

<enrico> +1

<AZ> +1

<Tpt> +1

james: As niklasl and enrico suggested, there's the concept of a "proposition". Whatever changes are made should recognize that.

niklasl: I think that's a good idea. Maybe we can coordinate on this.

pchampin: No mention to mention the notion of Proposition in concepts; it's already defined in a PR against semantics.

RESOLUTION: rephrase the definitions of triple and triple terms in RDF concepts according to w3c/rdf-concepts#150

<gb> Issue 150 Nature / role of triples (by pchampin) [needs discussion]


@ktk ktk removed the needs discussion Proposed for discussion in an upcoming meeting label Feb 6, 2025
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

5 participants