search

KNowledgeOnWebScale / surface

RDF Surfaces
https://knowledgeonwebscale.github.io/surface/
7 stars 1 forks source link

is N3 the best syntax for surfaces? #4

Open pchampin opened 1 year ago

pchampin commented 1 year ago

I understand the benefit of having an N3 based syntax, since I believe that @josd 's implementation of surfaces is based on N3. However, I find that syntax a little too verbose, and counter intuitive in the fact that blank nodes have different scopes from the point of view of N3 and from the point of view of surfaces. E.g.

# prefixes
(_:b) log:inNegativeSurface { _:b a :Unicorn }.

N3 says that _:b is scoped to the document, while Surface says it is scoped to the negative surface...

Furthermore, since Surface is as expressive as FOL, it would be possible in theory to implement N3 in a native Surface system -- so subordinating Surface to the N3 syntax seems like a bad signal to the community.

pchampin commented 1 year ago

see also #5

phochste commented 1 year ago

Indeed, there can be (and we had them internally already during presentations) questions about the verbosity of the syntax. This is something that can evolve. For now the syntax fits its purpose, the logical semantics should work regardless of the syntax. The goal is to open the discussion and invite more implementations and see what works or not.

We had very good reasons to use N3 as the first serialisation choice for RDF Surfaces (possibilities to group triples, sub graphs, the many built-ins we will need, the fact that the first RDF Surfaces implementation is in N3). The syntax of N3 is very well suited for RDF Surfaces. Indeed, as you state the semantics of N3 with the implicit scoping rules of blank nodes in N3 is an issue (in RDF Surfaces the scoping is explicit).

From a technical viewpoint we first want to be clear what we semantically mean with blank nodes and probably at this stage need to be explicit where the semantics are different from N3. This would be a very good agenda point for the W3C group to discuss what we are going to do about it.

Subordinating, profiling , extending N3 is a choice of words that are for us too early to make the decision on. We first would like to gather feedback. If RDF Surfaces could implement N3 (we don't know yet), it would still be N3. There are more examples of computer languages that can be written in its own language.

pchampin commented 1 year ago

@josd, replying you your comment there in this thread, which is more on topic :)

For me it is really nice to have it in N3 esp. for its built-ins and some surfaces are just built-ins.

I do not question the practical aspect. :)

It is also very nice to see a surface as, yes, just a triple so that we can reason over them and annotate them as RDF-star triples

It is nice, yes, but it is also a slippery slope, because it departs from the original vision. This may or may not be a good idea, but this should be a reflected design choice, not a side effect of the implementation.