– DRAFT –
RDF-star WG biweekly focused meeting

Feedback KG Forum

ktk: we had the KG forum last week
… a few people from the group were there

enrico: I was the only academic, it was a great experience,

ktk: there was interest in the work we do here

enrico: I was at CAiSE
… 90% of papers were related to LLMs

ktk: Olaf presented a proposal for lists at ESWC

<AndyS> https://awslabs.github.io/SPARQL-CDTs/spec/latest.html

ktk: it's a datatype for lists

<pchampin> https://2024.eswc-conferences.org/wp-content/uploads/2024/05/77770226.pdf

<pchampin> https://www.w3.org/community/dataspaces/

pchampin: there was a workshop organised by Stefan Decker related to a community group on dataspaces
… they want to propose best practices on publishing dataspaces
… dataspaces are a big thing in Europe

1: Map the steps to get to 2: vote on a working baseline and 3: map further work testing the use cases and verifing well-formness 1

ktk: we must figure out how to get more concrete in the WG
… we already made some steps on point 1. mapping

niklasl: the concerns mentioned by tl and pfps I share

enrico

enrico: I tried to summarise what I've heard
… we now have 1 profile and there is a baseline
… there is a basic graph definition were triples are unrestricted
… this would still be simple re. pattern matching
… we introduce the well-formedness constraint
… then in RDF entailment is only defined in the well-formed fragment
… there is a vocabulary that can only be used in certain way for RDF entailment
… we restricted the annotations to be functional
… annotations can only have opaque triple in object terms
… Some criticise this saying we don't want to have everything in one syntax
… some want to have opaque triples, other transparent, or semi opaque
… We could have 2 layers; one with simple entailment and when we have RDF entailment, we introduce restrictiosn

pchampin: one question to enrico
… there is a discrepency between what you describe and what I read
… I don't think you define "simple semantics" in your document

enrico: it is defined there

pfps: my main concern is that it is a kitchen sink not a baseline
… we get too much with this proposal

enrico: this is a proposal where you have everything and then we can compare to others with less

enrico: my understanding of "baseline" is that if you want X, you can find it in the baseline

<pchampin> It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove (Antoine de Saint Exupéry) https://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry

AndyS: this is a "baseline document", not a baseline in the sense of minimal
… by having a starting point, we can say "this is better because...", "this is this because..."

<tl> +1 to AndyS

AndyS: what I like in enrico's proposal and niklasl is that the ...
… split of the data model syntax is kept minimal
… and there's abstract syntax for different flavours

gkellogg: I'm suprise to see that we have in the well formed RDf tripple term appear in subject or object
… I don't recall that we had a discussion whether we can have a triple term in subject position

enrico: only in well-formed you have certain restrictions

<niklasl> +1 to gkellogg on simplifying things with triples only as objects

gkellogg: for people who implement, they want to have base implementation that make simplification and having triple term in subject can have real world implications

niklasl: we can address gkellogg's concerns
… it's good we can put everything on the table and compare
… how do you decide whether a triple term is opaque or transparent?
… is it the predicate or something else?

enrico: you need a way in the syntax to represent the different things
… how to decide the nature of the term is based on the position
… we should have a label to refer to syntactic sugar we have

<Zakim> TallTed, you wanted to check whether "triple term" is now being a special literal, or some other kind of entity

TallTed: currently, triple term is a special kind of literal
… this is a problem for tools that restrict literals to object position
… this change can have important performance issues

<niklasl> +1 to TallTed, that would be (IMHO too) radical (though it is a theoretical necessity for some entailments)

enrico: syntactically, these are not literals; they are just interpreted as literals

niklasl: triple terms are not literals but "literal-like"
… I'm not completely sure how the baseline really works
… how it works wrt entailments

<enrico> Denotation of opaque triple terms: [I+A](r) = IL(SRE(r)) if r is a opaqueTripleTerm

<enrico> SRE maps an opaque triple term to a literal

niklasl: is a token of a triple entailing the resource ???

pchampin: focusing on AndyS's meta proposal

<niklasl> Can a token of a triple also entail that it "references" the subject, predicate and object *resources*?

pchampin: I've concerns about this being too big but can live with it
… let's keep in mind that this is not whether it is perfect or not but is this something we can live with

<pfps> Note that just because a syntactic type is used in several places that does not imply that it has the same meaning in those places.

gkellogg: how can we interpret triple terms containing bnodes
… the mapping from bnode in syntax to bnode is made to be parser but how does it work here

<TallTed> I can live better with smaller "baseline" to which we add, than with larger "kitchen-sink (baseline?)" from which we subtract, because when we run out of time, it's easy to not add any more, but it's hard to then subtract what remains as problematic

enrico: the name of a bnode is always irrelevant
… what's relevant is whether a mentioned bnode is the same as another occurence of a mentioned bnode
… in the abstract syntax, one can have a function from bnode to something which is well defined

gkellogg: there are corner cases that need be discussed

niklasl: I'd like to address the "hasAnnotation" etc.

<pfps> +1 to TallTed

<pchampin> good point

TallTed: we may be in more trouble to start with this "baseline" and make subtractions, rather than something to which we can add

enrico: peopel understand "annotate" differently
… we can change/restrict the proposal if needed
… and start the document from well-formed fragment

<Souri> +1 to TallTed

tl2: if I +1 this proposal, it does not mean I endorse, it's that I think it's useful

<niklasl> Yes, baseline, not "will go to REC as is" ;)

<TallTed> is there a draft proposal?

pchampin: I sympathise with TallTed's point
… but if time is the argument, I hope we will be time efficient
… by finding what needs to be removed from the "baseline" proposal
… we may lose time going one way or the other

TallTed: we failed to become more efficient in the past years

<pfps> +1 to TallTed

TallTed: the baseline should be the minimum we can do, instead of the "kitchen sink"

AndyS: everybody has a different idea of what is "simple"

<pfps> At several times in the past I thought we were very close to accepting something like https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22transparent%22

tl2: I think it's better to have the big picture and when someone proposes something, we have this "baseline" to compare to

Souri: I prefer starting at a minimum baseline
… but we could approach things from both sides
… and hoepfully we meet in the middle

<doerthe> I am a little bit afraid of voting on a document which changes every minute (but I trust you Enrico :) )

<tl2> minimum: annotating ref. transparent asserted triple terms. maximun: + unasserted triple terms, + referential opacity, + graphs

niklasl: we can agree that this [enrico's baseline"] is the maximum baseline

pfps: there has been proposals that have been more maximum than this

<niklasl> I mean maximum that we've converged upon.

<niklasl> Not "semantics for multiple, modal datasets"... :P

<pfps> At one point there was a proposal that allowed direct specification of which components of a triple term were opaque and which were transparent. This is decidedly bigger than the "baseline".

<niklasl> Fair point.

<TallTed> Please, what *is* the draft proposal? What (URI, please) *is* the "document" now being discussed?

<niklasl> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22baseline%22

<tl2> @pfps thanks for remembering :)

Souri: having unrestricted fragment is not minimum

ktk: is enrico's proposal the maximum among the things that we considered seriously?

pchampin: let's have a strawpoll
… we don't need to do it synchronously
… we can do it by email

<TallTed> straw polls are useful, and are noncommittal

pchampin: I can write the proposal or sync with the chairs

<TallTed> please use the web polling tools, pchampin!

<TallTed> voting via email thread is beyond troublesome

<gkellogg> +1 to TallTed; use a polling tool rather than count email responses.