Re: RDF* vs RDF vs named graphs

> On Nov 30, 2020, at 3:21 AM, Miel Vander Sande <miel.vandersande@meemoo.be> wrote:
> 
> That's valid and I also see the merit of having it as part of RDF* rather than N3 (then should be well aligned and the nquads/trig syntaxes would be rooted).  
> But AFAIK nobody actually officially dismissed including graph annotation, so why not gather the stakeholders from enterprise, make a joint request for scope expansion, and have a structured discussion there? Evidently, a broader scope should come with the necessary engagement to manage the debate, follow-up on issues, and draft the specs. Let's approach this positively, this group is an opportunity :)

I have advocated formalizing the meaning of Named Graphs when the graph name is a blank node which is also used as the subject or object of a triple in another graph. This is basically how I’ve implemented N3 myself.

Additionally, this is consistent with the implementation of Named Graphs in JSON-LD, where a graph is often a property value, and there is specific support (graph containers0 for making this work well with implicitly named graphs (see Named Graphs in JSON-LD 1.1 [1]). Among other things, the use of graph containers is iimported to Verifiable Claims.

I advocated the use of Named Graphs as a way of supporting the Property Graph use case at the Berlin Graph Data Workshop in 2019, and used the JSON-LD examples as evidence of how this can be used to annotate graph edges, but there did seem to be a lot of momentum behind Olaf’s proposal.

In the mean time, I’ve become agnostic, and have also implemented triples-as-resources across my implementations, but now would be the time to reconsider formalizing the semantics of Named Graphs, at least insofar as they can support the RDF* use cases. Also, I find the N3/JSON-LD way of effectively describing graphs as literals conceptually easier to understand, although, it results in the edges being annotated be contained within a separate graph, rather than as part of the default graph..

Gregg

[1] https://www.w3.org/TR/json-ld11/#named-graphs <https://www.w3.org/TR/json-ld11/#named-graphs>

> Op ma 30 nov. 2020 om 11:56 schreef james anderson <james@dydra.com <mailto:james@dydra.com>>:
> 
> > On 2020-11-30, at 09:48:18, Miel Vander Sande <miel.vandersande@meemoo.be <mailto:miel.vandersande@meemoo.be>> wrote:
> > 
> > ...
> > 
> > I appreciate the work this group is doing in terms of making the interpretation of reification clear and usable. Its main goal is still to provide compatibility with the PG world, where properties over a group of edges simply doesn't exist. I think this limited scope actually helps getting somewhere within reasonable time. 
> 
> in order for this effort to yield a useful result it will need to do more than "provide compatibility with the PG world”.
> during the call last friday, one exchange included
> 
>     blake: I want to inquire a bit to see the aspects of embedded graph, embedded quad
>     <thomas> +1 to blake: keeping the possibility open to have embedded quads in the future
>     pchampin: A very good question by blake. There should be an issue for that in the repo. Yet another separate question 
>     ... that need to be checked and discussed 
>     ... Anyone wants to react?
>     <pchampin> ACTION: blake to submit an issue on embedded quads
> 
> that is, quads are seen as “something to be discussed”.
> the statistics on our sites suggest a stronger imperative.
> while triples dominate quads on a free site by a ratio of five to one, which would suggest that to claim pg-compatibility suffices, on an enterprise site the ratio is fifty to one in the opposite direction.
> in those contexts, if rdf* does not provide for quads, it will be of little use.
> 
> ---
> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com <http://dydra.com/>
> 
> 
> 
> 
> 
>