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

Named Graphs extension vs other ways #140

Open
VladimirAlexiev opened this issue Feb 23, 2023 · 11 comments
Open

Named Graphs extension vs other ways #140

VladimirAlexiev opened this issue Feb 23, 2023 · 11 comments
Labels
defer Deferring this issue until we have established the N3 standard.

Comments

@VladimirAlexiev
Copy link
Contributor

VladimirAlexiev commented Feb 23, 2023

https://w3c.github.io/N3/spec/#rel-n3-trig explains:

  • graph :g {:s :p :o} is TriG not N3
  • :g sem:quotedGraph {:s :p :o} is N3

I have two questions/desires:

{id :g  
  :s1 :p1 :o1.
  :s2 :p2 :o2}

Proposed editorial changes for that section

@doerthe
Copy link
Contributor

doerthe commented Feb 23, 2023

The main reason we did not discuss the direct integration of TriG was mainly the lack of semantics. It is not always clear, which semantics the creator of a document uses, therefore we propose to use a predicate between name and named graph wich clarifies that. If we would go for direct support of TriG, which semantics would you propose and why?

@VladimirAlexiev
Copy link
Contributor Author

VladimirAlexiev commented Feb 26, 2023

@doerthe Named Graphs are a basic part of RDF 1.1: https://www.w3.org/TR/rdf11-concepts/#dfn-named-graph, and all repos support Quads.

  • if you write in TriG
<https://example.org/graph> {
  <https://example.org/s1> <https://example.org/p1> <https://example.org/o1>.
  <https://example.org/s2> <https://example.org/p2> <https://example.org/o2>
}
  • this comes out in NQuads like this
<https://example.org/s1> <https://example.org/p1> <https://example.org/o1> <https://example.org/graph>.
<https://example.org/s2> <https://example.org/p2> <https://example.org/o2> <https://example.org/graph>.

There's neither a need nor an opportunity to use a special predicate to relate the graph to its name.

So I'm a bit unsure of your question. Do you mean that:

VladimirAlexiev added a commit to VladimirAlexiev/N3 that referenced this issue Feb 26, 2023
@gkellogg
Copy link
Member

There's still a pretty big gulf between RDF 1.1 with datasets and N3, which doesn't rely on the notion of datasets. Instead, there are graph literals. Additionally, as you mentioned, named graphs in RDF 1.1 have no semantics, while quoted graphs in N3 do have semantics.

Still, I think we should say something about this. One way might be with owl:sameAs to relate something like:

<https://example.org/graph> = {
  <https://example.org/s1> <https://example.org/p1> <https://example.org/o1>.
  <https://example.org/s2> <https://example.org/p2> <https://example.org/o2>
}

to a named graph, but again there are no semantics. I would not be a proponent of adding more syntactic sugar, but GRAPH :n {...} could be taken as syntactic sugar for :n owl:sameAs {...}. Without the GRAPH keyword it would be difficult to parse without extending the N3 grammar, which was a pain to do for TriG IIRC.

@william-vw
Copy link
Collaborator

@VladimirAlexiev Just to make sure we're on the same page - from the RDF Datasets WG note, which is referenced from your RDF11 Concepts link to define named graph semantics:
(bold added for emphasis)

RDF defines the concept of RDF datasets, a structure composed of a distinguished RDF graph and zero or more named graphs, being pairs comprising an IRI or blank node and an RDF graph. While RDF graphs have a formal model-theoretic semantics that determines what arrangements of the world make an RDF graph true, no agreed formal semantics exists for RDF datasets.

And (idem):

An RDF dataset is defined as a collection of RDF graphs where all but one are named graphs associated with an IRI or blank node (the graph name), and the unnamed default graph [RDF11-CONCEPTS]. [..] However, discussions within the Working Group revealed that very different assumptions currently exist among practitioners, who are using RDF datasets with their own intuition of the meaning of datasets.

Hence, more specifically:

the meaning of named graphs and RDF datasets https://www.w3.org/TR/rdf11-concepts/#section-dataset is not well defined??

There are currently no agreed-upon semantics at all, hence the need to use a custom predicate between name and named graph that reflects the intended semantics.

@TallTed
Copy link
Member

TallTed commented Feb 27, 2023

but GRAPH :n {...} could be taken as syntactic sugar for :n owl:sameAs {...}.

Not in the way that OWL defines owl:sameAs, which is to say "the identifier on the left dereferences to the same entity as the identifier on the right"; in other words, the identifier on the left and the identifier on the right coreference the same entity.

I do not believe there is any intent in any syntax to say that {...} is an identifier which could refer to whatever identity :n might reference.

@gkellogg
Copy link
Member

It says that it's the same entity, not identifier; I don't quite follow why both entities have to have identifiers, or of a quoted graph could be considered to be an identifier (quoted triples in RDF-star are identifiers, I believe).

Of course, you couldn't say this in RDF, as the graph name has no semantic relationship to the graph it names. In N3, you might be able to say that an identifier can identify a quoted graph; I believe I've seen it in examples or tests.

But, however it's done, something should be said to relate the concepts, to the degree the inherent difference in semantics don't get in the way.

@william-vw
Copy link
Collaborator

@VladimirAlexiev I'm assuming these posts answered your question (as there was no follow-up from your end). If not, feel free to re-open this issue.

@VladimirAlexiev
Copy link
Contributor Author

VladimirAlexiev commented Apr 1, 2023

@william-vw please reopen the issue since I cannot do it.
(I've corrected the examples on top to use graph name :g consistently).

@william-vw Ok, I agree with you that there's no commonly agreed semantics for named graphs.

However, I disagree that the user must select a predicate to relate a quoted graph to its name.

The quad model, SPARQL FROM/USING/WITH, and all semantic repos support named graphs.
When I store this in a repo:

graph :g {:s :p :o}. # TriG
:s :p :o :g. # NQuads

It's neither relevant nor correct to ask "what's the predicate that relates :g to its "content" {:s :p :o}": they are just stored in the same quad.
Similarly, when I store this:

:s :p :o. # TriG or Turtle
:s :p :o. # NTriples

it goes to the default (null) graph, no questions asked:

I want to extend this topic by asking: what is a reasonable way to store N3 in semantic repositories?
I think the only option is to treat quoted graphs as name-less (anonymous, blank-node-named) graphs:

# N3
{:a :b :c. :a1 :b1 :c1} => {:d :e :f}

# stored as NQuads
:a  :b  :c  _:g1. # anon graph
:a1 :b1 :c1 _:g1. # same anon graph
:d  :e  :f  _:g2. # new anon graph
_:g1 log:implies _:g2. # null graph

But using blank nodes is not always a good practice since they make debugging/browsing/sharing harder.
So now, the original issue can be reformulated as:
How to give a name to a quoted graph, rather than it being stored as an anon graph?

N3 may define a dedicated predicate to associate graph name and content, eg

{:a :b :c} log:graphName :g. # OR:
:g log:graphContents {:a :b :c} 

However, I think it'll be better if it defines a dedicated syntax, since Trig, SPARQL and Nquads have such special syntax.
Eg:

graph :g {:a :b :c} 
# OR
{id :g  
  :a :b :c}

I also think we should define some rules:

  • A quoted graph may have 0 or 1 names
  • If a quoted graph has no name, then a unique blank-node is assigned as its name (note: the name is not null!)
  • Top-level triples are placed in the default graph. There's only one such graph, and it has no name (its name is null)
  • One can refer to a quoted graph by its content (expressed in brackets), or by its name (if a name has been assigned). Eg the following are equivalent (except the assignment of names):
{:a :b :c. :a1 :b1 :c1} => {:d :e :f}.

graph :g1 {:a :b :c. :a1 :b1 :c1}.
graph :g2 {:d :e :f}.
:g1 => :g2.

This opens new opportunities, since the same graphs can now participate in more relations, eg:

:g1 => :g2.
:g3 => :g2.

But I think it'd also complicate N3's semantics, and I'm sure there may be unintended consequences.
@william-vw and @josd Do you think this is feasible?

@VladimirAlexiev
Copy link
Contributor Author

VladimirAlexiev commented Apr 1, 2023

The complications/unintended consequences don't come from me, I think they're already present in N3NamedGraphSemantics .

Has the semantics of this extension been explored/defined?
Eg which of these are possible/allowed?

  • write rules using graph names
{
  ?g1 sem:impliesByName ?g2.
  ?g1 sem:quotedGraph ?graph1.
  ?g2 sem:quotedGraph ?graph2.
} => {
  ?graph1 => ?graph2
}
:g1 sem:quotedGraph {:s :p :o}.
:g2 sem:quotedGraph {:a :b :c}.

# is this equivalent to 
{:s :p :o} => {:a :b :c}
  • one name, two different contents (then would sem:impliesByName generate 2 rules?):
:g sem:quotedGraph {:s :p :o}, {:a :b :c}
  • same content, two names
{
  ?g1 sem:addName ?g2.
  ?g1 sem:quotedGraph ?graph
} => {
   ?g2 sem:quotedGraph ?graph
}
  • same graph participates in multiple rules, eg can be inferred by different means:
:g1 sem:impliesByName :g3.
:g2 sem:impliesByName :g3.

The only difference in my proposal is that one could use graph name and content (quoted graph) interchangeable, i.e. save himself the sem:quotedGraph and sem:impliesByName predicates.

@william-vw william-vw reopened this Apr 1, 2023
@william-vw
Copy link
Collaborator

@william-vw please reopen the issue since I cannot do it. (I've corrected the examples on top to use graph name :g consistently).

@william-vw Ok, I agree with you that there's no commonly agreed semantics for named graphs.

However, I disagree that the user must select a predicate to relate a quoted graph to its name.

Just to be clear: this predicate is not only used to relate a quoted graph to its name, but also to indicate the intended semantics (since, as you know, there are many possible ones). There can indeed be syntactic sugar to avoid this, such as the TriG named graph syntax.

But, in that case, we'd still be using quoted graphs behind-the-scenes. N3 must assume a consistent meaning for quoted graphs, as they are a pivotal part of the language. And - if we represent named graphs using N3 quoted graphs, they will have the same semantics, unless specified otherwise. From Arndt et al:

"This semantics assumes named graphs as occurrences of RDF graphs: one can say that a named graph comprises a quoting of an RDF graph. Moreover, a graph name is defined as denoting its named graph pair within the dataset. This
allows one to describe a particular graph occurrence using the graph name as subject or object in RDF statements; indicating the graph provenance, such as retrieval date, author and source, version, etc."

But, as part of this syntactic sugar, one could include annotations to indicate different semantics (to avoid having to use predicates).

The quad model, SPARQL FROM/USING/WITH, and all semantic repos support named graphs. When I store this in a repo:

graph :g {:s :p :o}. # TriG
:s :p :o :g. # NQuads

It's neither relevant nor correct to ask "what's the predicate that relates :g to its "content" {:s :p :o}": they are just stored in the same quad.

That's because, AFAIK, semantic repos don't really assume a semantics and rather leave it up to the user to do this.

Similarly, when I store this:

:s :p :o. # TriG or Turtle
:s :p :o. # NTriples

it goes to the default (null) graph, no questions asked:

Let me separate your second question into a different issue!

@TallTed
Copy link
Member

TallTed commented Apr 3, 2023

  • A quoted graph may have 0 or 1 names

Perhaps for the various serialization syntaxes, but I see no reason why there could not be unlimited owl:sameAs coreferring names which refer to the same quoted graph.

@william-vw william-vw added the defer Deferring this issue until we have established the N3 standard. label Jul 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defer Deferring this issue until we have established the N3 standard.
Projects
None yet
Development

No branches or pull requests

5 participants