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

On 9/29/25 10:54, Dan Brickley wrote:
> . . .
> 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.

Or perhaps the semantics of each named graph could be declared 
explicitly, on a per-named-graph basis:

    :myNamedGraph1 :hasSemantics :X .
    :myNamedGraph2 :hasSemantics :Y .
    :myNamedGraph3 :hasSemantics :Z .

where :X, :Y and :Z are URIs that signify the most commonly used named 
graph semantics, and :hasSemantics is a standardized predicate for 
indicating named graph semantics.

David Booth

> 
>     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/
>>     <https://www.linkedin.com/in/filipkolarik/>
>

Received on Tuesday, 30 September 2025 15:25:24 UTC