Re: Feedback on RDF Graphs: Conceptual Role and Practical Use Cases

On Thu, 25 Sept 2025 at 08:20, Pierre-Antoine Champin <pierre-antoine@w3.org>
wrote:

> Hi Filip,
> On 19/09/2025 22:50, Filip Kolarik wrote:
>
> Dear Semantic Web Community,
> I’m seeking feedback on the conceptual and practical aspects of RDF graphs.
>
> In RDF 1.2, an RDF graph is defined as: "An RDF graph is the conjunction
> (logical AND) of all the claims made by its asserted triples." This
> definition captures the logical aggregation of triples, but it leaves open
> questions about how graphs are used in practice.
>
> Indeed. RDF Semantics is only defined for a given graph. How you construct
> that graph (e.g. by picking and aggregating different RDF resources based
> on your own criteria) is out of scope of the specification -- even though
> that's also an bunch of interesting questions :)
>
>
> I would appreciate the community’s insights on questions such as:
>   * How do you interpret the role of graphs?
>   * Are graphs primarily conceptual constructs to organize triples, or are
> they treated as concrete, addressable units in practice?
>   * Do you see named graphs as a way to scope statements, manage
> provenance, or isolate data for processing, while the “default graph”
> serves a different purpose?
>
> To be clear: named graphs and datasets are defined
> <https://www.w3.org/TR/rdf11-concepts/#section-dataset> in RDF's abstract
> syntax, but are not covered by RDF Semantics. The reason is that, back in
> 2014 when RDF 1.1 was specified, datasets were already largely deployed,
> and used in many different ways (including the ones you list above). The
> working group at the time considered that it could not decide on a specific
> semantics for datasets and named graphs without breaking many people's
> implementations... That's the reason of this status quo.
>

It doesn't seem a giant problem. We probably have enough experience now to
characterise 2, 3 or however many common patterns for using named graphs in
RDF applications and platforms. Metadata about the way a particular
repository manages and names its graphs should be fairly straightforward to
describe in RDF. Any standardization could be funneled into that kind of
descriptive role.

> So yes, you can use named graphs for all of these things, just remember
> that this will not be broadly interoperable. In other words, if you send
> your dataset to someone else, or if you make it available via a SPARQL
> endpoint, you will need to provide additional off-band knowledge explaining
> what the (custom) semantics of your named graphs is. This may not be an
> issue in some cases, but in it may be in others.
>
> With RDF 1.2's triple terms, on the other hand, we have a way to address
> all these use cases *explicitly* in a single RDF graph: you can describe
> triple terms (or sets thereof) with dedicated vocabularies (for provenance,
> or confidence, etc.), and have this knowledge included in your RDF graph,
> and available for reasoning.
>
> It does not mean that named graphs will disappear -- most systems using
> them today will probably continue to do so if that works for them. But
> triple terms provide an alternative design options for new systems (or for
> migrating some old ones).
>

triple-terms sound like they address usecases at the level of a particular
triple, or perhaps a small bundle of related triples. Named graphs can
operate usefully with graphs populated by millions or billions of triples.
Is it realistic to use triple terms for the latter too?

Dan



>   pa
>
> PS: this is only my personal position on the subject; this is not an
> official statement from the Working Group
>
>
>   * How do you decide when to create separate graphs versus keeping data
> in a single graph?
>   * In your experience, does the choice of graph boundaries affect
> reasoning, querying, or data integration in practical applications? For
> instance, do you treat multiple graphs as separate units, or are there
> scenarios where it’s helpful to merge graphs and process a subject’s
> properties across them?
>
> Any references, examples, or experiences you can share would be extremely
> valuable in understanding the balance between the conceptual model and its
> practical applications.
>
> Thank you for your time and expertise.
>
> Best regards,
> Filip
> https://www.linkedin.com/in/filipkolarik/
>
>