Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Storing N3 in semantic repos #173

Open
william-vw opened this issue Apr 1, 2023 · 2 comments
Open

Storing N3 in semantic repos #173

william-vw opened this issue Apr 1, 2023 · 2 comments
Labels
defer Deferring this issue until we have established the N3 standard.

Comments

@william-vw
Copy link
Collaborator

william-vw commented Apr 1, 2023

from @VladimirAlexiev:

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?

@william-vw
Copy link
Collaborator Author

@VladimirAlexiev This ties into an older discussion on "fitting" N3 into RDF stores. The relevant issue was closed back in the day since there wasn't much interest in continuing down that path.

Tying in @doerthe here as well as she would have more insight into the impact on N3 semantics.

@gkellogg
Copy link
Member

gkellogg commented Apr 1, 2023

How is graph :g1 {:a :b :c. :a1 :b1 :c1}. really any different than {:a :b :c. :a1 :b1 :c1} = :g1? That TriG/SPARQL syntax created some unfortunate branches in the TriG grammar, and = is already a stand-in for owl:sameAs. Are the semantics of naming graphs substantially different than what owl:sameAs provides (at least as hypothetically extended to consider graphs).

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

No branches or pull requests

2 participants