RDF-Star WG biweekly meeting

Meeting minutes

<Tpt> Regrets for today

Approval of minutes from the last two meetings: 1 , 2

<pfps> Both minutes look fine.

ora: look at minutes - any worries, concerns?

<AndyS> LGTM

<ktk> PROPOSAL: Accept last week's minutes https://www.w3.org/2024/03/07-rdf-star-minutes.html

<ora> +1

<pchampin> +1

<pfps> +1

<AndyS> +1

<niklasl> +1

<pfps> And two weeks ago minutes

<pfps> The pointer is to two weeks ago, not last week.

<olaf> +1

<ktk> PROPOSAL: Accept last week's and two week's agos minutes https://www.w3.org/2024/03/07-rdf-star-minutes.html

<ktk> PROPOSAL: Accept last week's and two week's ago minutes https://www.w3.org/2024/03/07-rdf-star-minutes.html and https://www.w3.org/2024/03/14-rdf-star-minutes.html

<ora> +1

<pchampin> +1

<niklasl> +1

<pfps> +1

<gtw> +1

<olaf> +1

<ktk> +1

<AndyS> +1

<doerthe> +1

<AZ> +1

RESOLUTION: Accept last week's and two week's agos minutes https://www.w3.org/2024/03/07-rdf-star-minutes.html and https://www.w3.org/2024/03/14-rdf-star-minutes.html

Proposal for next week's discussion 3

<pfps> The link for "next week's discussion" is broken.

ora: topic for next week

andy: meta suggestion - do we need 2 hours?

ktk: alternating?

andy: yes, still alternating

<niklasl> +1 to alternate admin/tech. I think 1 h still may be a bit too little at times? 1.5?

ora: would like to have the option to talk longer when the need arises
… and we do know in advance what we talk about, so could plan accordingly
… proposal: go for 1 hour meetings every time, extend if needed, always start at the same time

<ora> PROPOSAL: Let's go back to 1 hr per week, still alternating between administrative and substantive discussions

<ora> +1

<pchampin> +1

<ktk> +1

<niklasl> +1

<doerthe> +1

<olaf> +1

<AndyS> +1

<AZ> +1

<eBremer> +1

<gtw> +1

RESOLUTION: Let's go back to 1 hr per week, still alternating between administrative and substantive discussions

ora: what do want to talk about next week?
… proposal: talk about if a single id can reify more than one triple term
… a bit worried about that

<pchampin> +1, "one triple" rather than "one triple occurrence"

<olaf> indeed, "... more than one triple term"

niklasl: un-starring a related topic, also RDF/XML

<AZ> I think you need to add a "/" at the end

<ktk> PROPOSAL: Discuss if a single id can reify more than one triple?

<niklasl> +1

<doerthe> +1

<gtw> +1

<AZ> +0

<ktk> +1

<olaf> +1

<eBremer> +1

<ora> +1

<AndyS> +1

<pchampin> +1

RESOLUTION: Discuss if a single id can reify more than one triple?

Review of open actions, available at 4

Review of pull requests, available at 5

<pchampin> w3c/sparql-query#143

<gb> Pull Request 143 RDF is a model, not a format (by TallTed) [spec:editorial]

andy: will handle editorial issue in line 4

pfps: mobile phone fiasco doesn't disappear
… most of our documents currently have very bad user interface
… proposal to do it right

niklasl: turtle and trig not ready because of semantics issue
… naming of annotations
… (not related to mobile phone issue)

ktk: we would have to go through different documents (the vast majority of them)

<AndyS> w3c/sparql-federated-query#17

<gb> Pull Request 17 again... model, not format (by TallTed) [spec:editorial]

pfps: can we undo old commits that cause problems?

ktk: should we fix one document, and then follow through with all the others?

pfps: that was the plan, with the semantics document, but we never had an agreement about the desired end state
… and my proposal would be "no change"
… which would mean revert all changes

ora: we need good user experience also on mobile devices
… and we need consistency across all documents
… but, how to do that is not clear to me
… does that involve changes to what we had before?

pfps: how to handle small view ports is a contentious issue

<ktk> w3c/rdf-semantics#30 (comment)

<gb> Pull Request 30 improve display on mobile phones (by domel) [spec:editorial]

ktk: pchampin, can you (???)

pchampin: not sure how to assess what a good solution is
… leaning towards reverting the changes, as peter suggests
… dominique's changes (???)
… CSS should be reverted to W3C standard

ktk: pchampin and me will give it a try

tallted: other groups probably have the same issues, maybe pchampin can gather some feedback from there

ora: let's revert, and then lets figure out who we need to go to to reach closer to perfection

Niklasl: added comment to PR mentioned in Dominik's mail from today

<pchampin> w3c/rdf-concepts#66

<gb> Pull Request 66 Updates rdf:JSON value space. (by gkellogg) [spec:substantive]

ktk: will get back to gregg and peter disagreeing on JSON value space

<Zakim> AndyS, you wanted to talk about sparql-federated-query PR

<pfps> The issue for rdf:JSON value space is that there needs to be an absolutely firm definintion of the value space and I don't see one now.

pfps: can't see a definition of the value space
… sorry, lexical space
… lexical space is decimal and doesn't work with binary precision
… text is defering to unspecified procedures

<pchampin> https://infra.spec.whatwg.org/

pfps: procedures not precisely defined

pchampin: this doc defines a transformation, maybe this could be brought in to help

<ktk> https://en.wikipedia.org/wiki/IEEE_754-1985

ktk: is this something different?

<AndyS> also - https://www.w3.org/TR/xmlschema-2/#double (esp last para)

pfps: this talks about some of the issues, but again doesn't say which decimal numbers should be used to represent a floating point number

andy: xml schema says something about that

ora: hates floating point numbers and suggests to get rid of them entirely

ktk: will try to work out a solution together with gregg and peter

pfps: xml schema doesn't have a canonical representation for floating point

<TallTed> https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.xml#float-canonical-representation