Open VladimirAlexiev opened 1 year ago
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?
@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.
<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>
}
<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:
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.
@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.
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.
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.
@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.
@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 :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?
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?
{
?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}.
{: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 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!
- 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.
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 N3I have two questions/desires:
id
keyword as used in https://w3c.github.io/N3/spec/#iriprplist :Proposed editorial changes for that section
TriG
toTriG vs N3 Named Graphs
PREFIX sem: <https://example.org/ns/semantics#>
is correct, as can be seen in https://github.com/IDLabResearch/N3NamedGraphSemantics/blob/master/3_3_quote/example.n3#L2. I was very surprised by this prefix, so needed reassurance.