RDF-Star WG biweekly long meeting

<AZ> Europe switches to daylight saving time on the 31st of March

Fallout from breakout day & well-formedness

Fallout from breakout day

<AndyS> +1 to standard starting content for RDF 1.2

Adrian: we had some slides presented by Ora, and a good number of participants (15 people, Ora, Adrian, Andy, Enrico, Niklas; and external people e.g. Michael McCool, Marcel Otto, Jerven Bolleman)

Ora: We should have a starter set of presentations on RDF-star

Adrian: Marcel Otto is working on a version control system based on RDF-star (in Elixir)

Ora: Michael McCool from IBM, working on IoT things; looking at how RDF-star is applicable

Adrian: WoT people looking into how to use RDF in Web of things

<ktk> https://en.wikipedia.org/wiki/NGSI-LD

Ora: there's an upcoming meeting on these things, e.g. NGSI-LD. What the role of RDF in this?

Adrian: unclear how/who use these technologies?

Dave: how can the improvements to RDF going on help out these things? People coming from PG backgrounds, how will semantic interop be aided by what is done for RDF?

Ora: We can talk about well-formedness, or the radical suggestion from Enrico.

Enrico's "radical" suggestion, https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Mar/0020.html

Enrico: The rationality of my proposal is to get rid of the rdf:reifies predicate, and use the macro instead.

<AndyS> Example please?

Enrico: we force people to use the macro, because it will be the only thing available.

Ora: but implementors have to connect the ideas with the property?

Enrico: yes. The semantics will be the same.
… the mapping will connect the triple terms. Automatically always well-formed.
… the predicate will not be available (??)
… the entailment problem that Dörthe showed will not surface
… we would be in the same position as with entailment for literals.
… a number of issues comes out of this well-formedness.
… we will suggest to use just the macro, otherwise you're on your own.

Ora: It's an attractive idea. We probably need time to digest that.
… It could make this simpler.

niklasl: we talked about it a bit before. It feels like I've seen similar suggestions. It looks attractive but I'm not sure if it is necessary.

<AndyS> https://www.w3.org/TR/rdf12-semantics/#rdfs_patterns rdfs3

niklasl: with the reifies predicate that Enrico wants to get rid of, we have kind of a macro.
… I can see both perspectives. The question that comes is we have the macro even in n-triples, correct Enrico?

enrico: I have no clue what will happen in n-triples.
… the only new term is this tripleReification term

niklasl: If we want to keep TripleTerm and rdf:reifies somewhere, it has to be put somewhere.
… It should still be there in the abstract syntax. If we don't have it there, we are re-visiting things one way or another.

<Zakim> Souri, you wanted to ask: 1) Is the macro just a suggestion? 2) Do I need to repeat the macro for every annotation? 3) I thought rdf:reifies range was going to be restricted to set of triple-terms of triple-terms only.

Souri: Property graphs allow edges without any properties.

Souri: PG allows edges without any edge properties. Here we have a definition that says there must be something.
… but here we have one triple, on a "higher" level, to express the reification.
… That would cause some issues with PGs.
… That is a difference with property graphs that may cause some issues.
… Is the macro just an addition? Is it the only way that can be used?
… Will the macro be the *only* way to use this?
… If we use the macro, do we have to repeat it for every reification?
… If we have the lower level thing, like _:e rdf:reifies <<(spo)>>, I can use the _:e by itself, without having to take the spo with me, right?
… only triple terms will be allowed as the value of rdf:reifies?
… I'm not sure if we should restrict ourselves to the higher level (macro??), or if we should allow the rdf:reifies with a triple term, and not enforce restrictions on that.
… I'n a binary relationship table, i don't have to have values on the relationship. Why do we have to put those restrictions in in RDF 1.2?

Ted: I'm pretty sure that when you identify something with an identifiers, we only need to use that identifier to talk about that.
… I'm struggling with reading the radical proposal, since the BNF is not really a BNF. It's halfway towards it, but something is missing.

<Zakim> AndyS, you wanted to ask for an example

Ted: Using a disciplined BNF would be helpful?

Andy: Is this the named occurrence only, which we had problems with before?

<AndyS> This is the same as the named occurrence proposal?

<AndyS> << _:e | :s :p :o >>

<AndyS> _:e

Andy: with << e | spo >> only, what are we talking about, the whole or only e?
… what is the difference from last time [and the radical proposal]?

Enrico: To Souri: In this proposal, we have exactly the same expressivity as with the well-formedness proposal. Property graphs should be exactly as encodable with this proposal.
… As Ted said: You don't need to repreat the reification, only the identifier.
… The problem with current option 3 proposal: apart from well-formedness, there is this major issue that a valid entailment from a well-formed graph generates a non-well-formed graph.
… the bnode entailed from the triple term.
… Re. BNF; it is true BNF. It is the BNF of RDF 1.1 with one other term.

<TallTed> BNF should have ```tripleReification ::= identifier '|' triple``` rather than ```tripleReification ::= identifier triple```

Enrico: To Andy: yes this proposal has the problem of connecting triple terms and its single element [name(??)]
… If people understand entailment, they may understand this (??)

Andy: the issue is the issue of well-formedness

<AZ> There is no BNF of RDF 1.1. There are BNFs of the serialisation syntaxes of RDF.

Andy: Why don't we adopt (??). With option 3 and the cleaned up semantics, we get an account of named occurrences.

Enrico: we are introducing triple terms; we don't know how to give a meaning to them, and then we introduce the macros

Andy: Souri has a use case: to write down just the edge

Peter: being able to write down edges is not a use case itself, so what is the use case that this is part of?
… What Enrico said about well-formedness can be said about all graphs.

<Souri> making a case for supporting bare edges: https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Mar/0009.html

Peter: There are things that are not using the macro, but use rdf:reifies; e.g. to say <john> :said [ rdf:reifies _:b ] .

<pfps> My comments boils down to saying that there are reasonable things that are not captured by the well-formedness criterion but that, to me, make sense, e.g., the example just above

Souri: it makes sense to have edges alone. E.g. some people works part-time, and I want to express a promise about them talking about an edge. Just state that there is an edge.
… in terms of binary relationships. I don't have to have an attribute for the edges. I want to relate them. We should not make it overly restrictive.
… people should have access to the lower level.

Enrico: To Peter - the only case for well-formedness, _:e rdf:reifies _:x - but then you can never reuse that bnode.
… With lists its sort of obvious when they're well-formed
… But it is less known here, so we have to educate them on where it makes sense.
… If we standardize lists by providing elements, and expect them to be used correctly.
… In the original RDF document, those were informal, just suggestions, not standardized.
… We *could* just *suggest* how to do reification, but that is a dangerous path.
… Do we have a grammar for well-formed lists, and well-formed reification?
… With the existential bnode for a triple term, it cannot be used again.
… I don't need triple terms to talk about *some* reification,.

Souri: my goal is simple - I want to have edges in property graphs, and should be able to to a 1:1 transformation to RDF 1.2. The other way around is not possible since RDF is more expressive, but at least the PG2RDF.
… I would like to be able to view the binary relationship, with no attributes, and represent it in RDF.

<TallTed> It MUST be OK to have some features in LPGs that are not in RDF, and vice versa, just like there are features in SQLs that are not in LPGs nor RDF! LPG != RDF != SQL

Souri: The transformation from LPGs to RDF should be as direct as possible.

<enrico> <<_:b | s p o>> a rdf:resource this is an edge with no edge properties

<TallTed> Grand Unified Theory remains out of reach in physics, and also in data models.

Ora: You mean standalone edges that have been named.

Souri: Yes.

Souri: I want a name, sitting there ready to be used.

<enrico> <<_:b | s p o>> a rdf:resource this is an edge with no edge properties

Enrico: See the well-formed example [above].
… maybe a bit verbose, but usable.

Souri: that is a workaround. I can use that, but why do we need that? Why can't we avoid it?

Enrico: as Andy, said, and this is option 4 [that we don't know if we talk about the occurrence term or the name?]

<AndyS> option 4 allows << _:e | :s :p :o >> .

Ted: There are things we can do in LPGs that we cannot do in RDF, just as there is in SQL. Just as there is no grand unification theory of physics, there is none for data models.
… I don't think we should treat this as a goal.

Souri: in the case of vertices/edges; edge properties were missing.
… associate a name with it makes it possible to point other edges. This goes beyond what PGs support. But we should be able to do this in RDF.
… There is nothing missing [in option 3] to prevent us from representing all of LPGs in RDF 1.2.
… Using SPARQL for these data structures is a practical thing, and we're very close to support that. Just some relaxation [on the well-formedness] restrictions enables this.
… We may have to do this to keep the customers satisfied.

Ora: So, Souri, the existence of the rdf:reifies statements is what you need?

Souri: Yes.

Ora: To Enciro, if macros protects us from seeing these, your proposal is still essentially option 3?

Ora: So, what about standalone nodes.

<niklasl> s/rdf:Resource/rdfs:Resource/

Souri: Yes, we cannot do that, without [the "use a type" workaround in IRC].
… How many vertices are going to be standalone? That is not a common case.
… We can label those or type them.

<AndyS> From before -- data << :e | :s :p :o >> :q :r . query -- SELECT * { ?a ?b ?c } results -- ?a=:e ?b=:q ?c=:r or ?a=<< :e | :s :p :o >> ?b=:q ?c=:r .

<TallTed> Note that rownum is an Oracle-ism, not in all SQL DBMS. Having a "hanging", "bare" Oracle rownum is closest to having a "hanging", "bare" SQL primary_key with no values in any other column. Perfectly legal, but not terribly exciting.

<TallTed> Also note that having "just the data" is almost never considered useful by users. *Querying* is when data becomes valuable. That's why SPARQL was so vital for RDF success.

Souri: But named edges will be more common.

Souri: very few things are so standalone (as vertices). But edges without properties are more common.

AndyS: I've put in an example from previous examples of named occurences. One example of why the ambiguity will get us into problems.
… In coming to a standard, we build a consensus among the group. I'm worried if we jump back to previous proposals without a clearly articulated explanation about why we are improving things.

ora: Ideally I don't want us to open it up again. This discussion should help undertanding weather we still have consensus around option 3.

well-formedness

enrico: Let's ignore the radical proposal and talk about well-formedness.

AndyS: I thought that is were we were. I was happy with the (??) well-formedness.

enrico: the notion of well-formedness has a number of technical problems. We can't define a BNF for it.
… Not in a pure BNF way.
… Plus the problem that these graphs simple entail RDF graphs that (??)
… Third issue was mentioned by doerthe. The current grammar is not correct because it enforces the two triples to appear immediatlely after each other.

niklasl: I have a hard time understanding the third requirement. The need for doing BNF for the well-formedness of reification, I don't see that need.
… why do we need to express it in BNF form?

enrico: I need to tell people what is the notion of well-formedness somehow.
… There is some technical issue to describe that in a way that it's easy to understand.

Souri: rdf:refies must have triple terms only. e rdf:refies cannot be used as graph name or as predicate. That would make it easier.

enrico: well-formedness is also required to say that triple terms alone are triple terms. they denote resources that are the abstract triple. We can only define the abstract that is well formed.

ora: What are our options for defining well-formedness, if we can't be using BNF. BNF was defined for something else and makes assumptions that syntax is some serial thing.
… But this is a set of logical conditions that need to hold. Why would we insist on going to use BNF for it if we have other vehicles.
… Well-formedness is like an assumption. They assume that the graph is well-formed.
… Originally we said outside of well-formedness, bad things could happen.

enrico: We can define a parser/formalism/grammer somehow and I think it should be done. It is going to be beyond what people are used to see with BNF, but it can be done.
… It's not a major problem for implementations. But being strict about well-formedness for me is important, otherwise I cannot explain what it means.

niklasl: I don't know why it feels hard now, we had this problem with literals all the time.

<AndyS> How to implement SUBJECT(?s) ?

niklasl: literals as well as tripleterms are primitives so to speak.
… What is the problem actually? In this entailed context we hit the problem all the time with literals. So the problem is not in the entailed graph but maybe when we serialize it.
… So where exactly is the problem and is it the same problem with literals, that would break stuff on serialization for a decade. But why has it not, or has it?

enrico: The problem from literals in subject position is a major problem. As implementer, you can choose to ignore this.
… but in RDFS it's a major problem
… It took several years to prove that the simple way is the right way.
… I'm not sure we can *not* have a rule that forbids some things.

niklasl: Maybe there was a mistake made: To say that literals are resources.
… For me that is the driving source of my way of comprehend this.
… That's why I am so adamant to not put them in a subject postion.

doerthe: The moment we have logical constructs and people put synatic restrictions on it, we always have a problem.
… Also I don't think we absolutely need a macro, I'm with Souri there. I don't think it causes big problem if we don't have it. But I'm not an implementer so maybe I miss things.

ora: It causes problem but the question is how much and for whom.

enrico: Literals, like IRI, is somethign that denotes resources. It's a term. This has been changed in RDF 1.1

<TallTed> pain for us (the standards writers) is preferable to pain for implementers (the software writers) which is preferable to pain for users (the data writers and queriers)

enrico: What is the problem? I can't use them like IRIS because two same but different literals are distinct. Not with IRIs, they are the same.
… The literal denotes itself.
… It's typical for databases, you can only have literals, not IRIs. And in fact in the real world, these constants are not the same. They are all values of attributes.

pfps: it's not true that RDF literals denote itself.
… With datatypes, they are different.

enrico: For simple literals it is the same.

pfps: simple literals are macros.

+1 to "simple literals are macros"

enrico: The syntax tells everything about the meaning of this symbol. I don't need somethign that tells me what this IRI means.

ora: I have the feeling this discussion is a rabbit hole.
… In the interest of making progress, we have to force ourselfs to be pragmatic about it.
… How much do we care about the pain that some of our discussions will be causing to some people or some groups. As much as we would like this to be perfect.
… Earlier we settlet on option 3, we had this idea of well-formedness. Now we need a reasonable definition on it.

niklasl: We do add complexity. Given that it seems that triple terms and literals share a characteristics, pretty much speaks for option 3 as it stands.
… Given the notion of well-formedness I'm not sure if it's the same as we want for lists.
… If the simple entailments things in practice didn't hurt to much, under the guide of pragmatism we should live with that? The theory should hurt more than the usage.
… It's like when we use internal database keys as RDF identifiers, it hurts when I think of that.
… What is the pragmatic approach? Maybe hurting the fewest people possible.

ora: that's exactly our challenge. We do in some way represent the larger RDF community.

Souri: Option 3 but with support for bare edges is something that would be very helpful.

doerthe: To answer Niklas. I see the semantics & logics in RDF as an added value. I see that we should be pragmatic but I still think that we should put this in our framework.

ora: that's not what I heard. If it's only about the semantics the job would be different.
… Not just with respect to what the users see every day but also with the theoretical semantics.

ora: I hope we all understand the somehow conflicting goals that we try to reach.
… At least in the abstract, I really liked the idea of well-formedness.
… Maybe we can attack the actual notion of well-formedness tomorrow in the semantics meeting.

AndyS: Not all issues are about the semantics.
… I had several examples where I didn't get answers back so far.
… N-Triples is one of them.

ora: Yes we have more to be done.
… Let us continue tomorrow at the semantics meeting.

Souri: Could someone write down informally well-formedness, as simple english sentences?

enrico: An informal definition is (??)

Souri: It would be nice a simple bullet point definition with some examples in RDF
… on the list.