– DRAFT –
RDF-star WG

Seeking consensus (cont.)

ora: like peters 4-point list from yesterday as a minimla base line
… no change to abstarct syntax
… no change t semantics

<pchampin> https://www.w3.org/2024/01/18-rdf-star-minutes.html#x077

ora: several concrete syntaxes have new shorthands
… a new notion of well-formed RDF

pchampin pushback on making reification the base line in discussion yesterday
… so seemingly no consensus on the chairs proposal

andy: address concerns about reification such as bloat and fragility

pfps: not sure changing reification vocab helps

andy how are things recorded

ora: optimization - what happens if someone uses the reification vocab instead of a shorthand syntax

enrico: leave out rdf:Statement in expansion and the actual stated statement

<AndyS> :e :isNameOf << :s :p :o >> .

<AndyS> (from the minutes yesterday)

pchampin: starting point of recent proposal was asserted statement
… agree that rdf:statement can be omitted
… is also not used in practice (just rdf:subject/predicate/object)

<niklasl> rdf:subject rdfs:domain rdf:Statement . # as defined

tl: but we might find it useful to subclass it as "fact" and "claim"

enrico: give suggestions for different classes of situation, like opacity

tl: might subclass statement into claim and fact

tl: we might find it useful to subclass rdf:Statement with things like Facts, Claims, maybe OpaqueStatement...

ora: possible implementation challenge if naming a triple requires to change if the name is used already

pchampin: same issue with reification vocab, so rather orthogonal

pfps: same problem when re-using IRIs

enrico: it's not enough to say "be careful". there should be more guidance

ora: what if two triples have the same name? still wellformed?

niklas: syntax helpfully gives a blank node name by default

<AndyS> -- :e :isNameOf << :s :p :o >> .

<TallTed> for potential future... https://hackmd.io/ keeps the two panes in sync, and allows for collaborative edits (which might be good or bad) of the markdown

pchampin: notion of wellformedness still needed. should say no multiple triples with same name
… "soft well-formedness"
… analog to constraints on the reification quad

tallted: there is already the restriction that an IRI refers to only one thing
… but that only applies to one snapshot of one graph
… we might define statement IDs like we define blank nodes, constrained to one graph

<niklasl> +1 for Ted's further clarification

enrico: an IRI always refers to just one thing, so an IRI would always refer to only ONE resource, no matter how many occurrences are named by that IRI
… so wouldn't want to have such a restriction
… the name doesn't name the triple but an occurrence (whatever that means exactly)
… necessarily a many-to-many relation between triples and occurrences of triples

niklas: when using inference there may be many triples refering to the same occurrence
… so should the name refer to the triple itself or the statement?
… i understand it as refering to the statement

<pchampin> +1 to build an assembly language

enrico: this construct could be used to define many kinds of reified triples

<niklasl> From RDF concepts: An RDF triple encodes a statement—a simple logical expression, or claim about the world.

<niklasl> https://www.w3.org/TR/rdf11-concepts/#entailment

enrico: should not be constrained more than w.r.t. well-formedness, and some best practice

<Zakim> pchampin, you wanted to ask how an "occurrences of A triple" is in a many-to-MANY relationship with "triples"...

pchampin: occurrence is a many-to-one triple relation
… rdf 1.1 doesn't have the notion of an un-asserted triple

andys: we need an issues list

souri: if the name of an occurrence may refer to many triples, then it represents a changing collection

<niklasl> <st> a rdf:Statement ; rdf:subject <s1> ; rdf:predicate <p> ; rdf:object <o> . <s1> owl:sameAs <s2> .

souri: and we can say things about that (possibly cxhanging) collection, right?

pfps: the current proposal doesn't allow a name to refer to multiple triple occurrences
… right now the name *is* the triple occurrence
… going that way is a major change to the proposal

pfps: on the meaning side there's allows only one thing. well-formedness is about syntax

tl: you are going into referential opacity

<niklasl> https://www.w3.org/TR/rdf11-mt/#reification # See _:xxx and _:yyy in the example.

pfps: well-formed-ness is a syntatic notion, semantics has nothing to do with it

tl: several triples can have the same meaning

pfps: triples are syntactic constructs; they occur in graphs; a graph is well-formed if some conditions on its triples are satisfied

<niklasl> "Rather, the reification describes the relationship between a token of a triple and the resources that the triple refers to."

pchampin: yesterdays discussion maybe let beyond teh current proposal
… atomicity is important for some members of teh group

<pfps> There is no need for internal documents to be syntactically well-formed, nor is there any need for internal RDF graph data structures to be well formed.

pchampin: the standard reification can not be the solution
… peter still seems to see it on the table

<enrico> << :w1 | :bill-clinton :related-to :hillary-rodham >> :starts 1975 . << :w1 | :42nd-potus :husband :1st-female-NY-senator >> :starts 1975 .

<pfps> ... in this sense - a system can enforce lots of well-formedness restrictions on its internal data structures.

enrico: this atomicity/well-formedness dogma i can not agree with
… it is giving a meaning to that construct

<AndyS> See are we agreed about atomicity?

enrico: which, as peter just that, is not possible

<Zakim> pchampin, you wanted to respond to enrico

pchampin: i said contradictory things
… the intended use of teh abstarct syntax seems to be many-to-one, occurrences of *a* triple

<pfps> In the current proposal

<pfps> << :w1 | :bill-clinton :related-to :hillary-rodham >> :starts 1975 .

<pfps> << :w1 | :42nd-potus :husband :1st-female-NY-senator >> :starts 1975 .

<pfps> expands to

<pfps> :w1 rdf:predicate :related-to .

pchampin: okay for many-to-many in teh abstarct syntax, however the intention seems to be many-to-one

<pfps> :w1 rdf:predicate :husband .

<pfps> ...

<pfps> which doesn't make sense.

pchampin: of course we don't enforce this

souri: assembly language is good, but we need a high level syntax
… atomicity in terms of wellformedness is a good thing to have
… the reification quad can have dangling links
… having an IRI name two triples should not lead t an owl:sameAs entauilment

<pchampin> I see well-formed-ness as something much "weaker" than closed world assumption, but agreed, they have some similarity

tl: yesterday, we didn't agree on being able to exchange the model
… it can be implemented in different ways

<TallTed> The biggest reason OWL (and inference/reasoning in general) is unpopular is the early misunderstanding of what owl:sameAs meant, which led to much dirty data which incorrectly used owl:sameAs forcing users to ignore/discard OWL-based statements.

tl: some people don't want to implement triple terms
… we can perfectly not exchange the model, only syntax

<Zakim> AndyS, you wanted to ask about atomicity

<enrico> does <<:a | :s :o :p>> :s1 :o1 . <<:b | :s :o :p>> :s1 :o1 .

<enrico> entail :a :same-as :b . ??

andy: we might get into problems with querying if we don't define a mapping to the abstract syntax in the model , e.g. when counting

<AndyS> s/require a new term/define a mapping to the abstract syntax/

<pfps> You answer this by expanding and using current entailment, not only no, but **no**!

enrico: we should not have strong well-formedness requirements, only prevent dangling links

<enrico> +1

souri: we should have both assembly level with all the possible powers, and a higher level language that prevents dangling links

<Zakim> pchampin, you wanted to note that I like the comparison to dangling links

souri: we need a language construct that makes users feel confident they can't make silly mistakes

<pchampin> :s :p

<pchampin> :s :p "o"^^

<pchampin> :e rdf:subject :s.

pchampin: the current abstract syntax already prevents against certain things like incomplete triples.
… we could do something like that for reification

<pchampin> :a :b << :e | :s :p

pchampin: ^ that we don't want

<pchampin> STRAWPOLL: do we think that the atomicty of "edges" is important enough that we can extend the abstract syntax to guarantee it?

<Souri> +1 to colloquial use of "edge" :-)

<AndyS> +1

<pchampin> +0.66

+1

<Souri> +1

<pfps> -1

<ora> +0

<niklasl> +0

<TallTed> +0

<pfps> -1 for the purposes of the discussion today

<enrico> -1

andys: if one doesn't want atomicity of edges, anything we do with the annotation syntax is suspect

pchampin: not more than the use of lists

<niklasl> ... or the RDF/XML shorthand for reified and asserted (using rdf:ID on a predicate)

peter: will put the document (that everybody sees right now) somewhere public

ora: ask everybody to review that document

<enrico> Why don't we have: STRAWPOLL: do we think that the atomicty of "edges" is important enough that we need to have a best practices section to explain it??

pchampin: w.r.t. to lack of consensus on strawpoll, does +1 mean "I can't live without this modification to the abstract syntax"?

andys: no. wg has to address the known deficiencies of reification

souri: same. we need that to get uptake

pfps: unclear what the current proposal is

<AndyS> From the minutes of 2024-01-18 -- :e rdf:nameOf << :s :p :o >> .

pfps: maybe somebody can write down was the agreement of yesterday was

ora: right now we can't know what the consensus is

pfps: too much confusion. we need better worked out proposals

tl: to answer pchampin's question: my +1 does not mean "we need to change the abstract syntax"
… I see Souri and AndyS's point about atomicity, but I believe the syntax provides the adequate guarantees

pchampin: notion of well-formedness is meant to provide the necessary guarantees if we don't add something to the abstract syntax
… would not be as strong as changing the abstract syntax but might be sufficient
… would like to investigate that route some more
… the importance of atomicity has been pointed out, now how can we get it without changing the abstract syntax

andys: there have been proposals, but not much engagement, but instead alternative proposals that don't build on prevuious work

souri: reification has been there forever. can we add to that an atomic concept?
… wellformed reification quad as a singleton. if we count, then we count those singletons, not reification quads

<Zakim> pfps, you wanted to say that the proposals have been from individuals, not subgroups of the WG

souri: otherwise user would have to query for (reification) triples

<AndyS> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0033.html + reification-based semantics

ora: peter please make your document available
… then the chairs will make known that this is what most people can agree on right now

<Souri> regrets for next week's short meeting -- I'll be on vacation

ora: title of peters doc: "a draft proposal for satisfying the main requirements of the working group"

<niklasl> Thought of an #RDFPRAGMA: <ex:t> := << <ex:s> <ex:p> <ex:o> >> to declare intent of well-formedness in N-triples (ideally but not necessarily directly followed by a contiguous set of that in actual triples). Very weak stuff of couse.

ora: high hopes that we can agree on this
… important that everybody reviews it

AndyS: I want it recorded in the minutes that I believe we must address th known issues of reifications