Meeting minutes
<TallTed> no-one else has joined zoom, so I'm aborting/adjourning...
<ktk> p+
<ktk> Timothe: around?
<ktk> ll
<ktk> open item 1
<ktk> close item 1
Approval of last two week's minutes: 1
ktk: Last week only 6 so we didn't accept the minutes.
… this week we'll look at 2 weeks worth of minutes
<ktk> PROPOSAL: Approve minutes 2023-07-20
<pfps> +1
<gkellogg> +1
<pchampin> +1
<niklasl> +1
+1
<ktk> <ktk> +1
<Tpt> +1
<Enrico> +1
RESOLUTION: Accept the minutes of 2023-07-20
<ktk> PROPOSAL: Approve last week's minutes
<gkellogg> https://
<gkellogg> +1
<niklasl> +0
<pchampin> +0
<ktk> <ktk> +1
+1
<pfps> +1
RESOLUTION: Approve last week's minutes
Brainstorming: “What still needs to be done” (Ora)
ktk: skip this brainstorming item (TPAC prep)
… until next week.
Review of open actions, available at
gkellogg: I have completed my action.
<pchampin> gb, status
<gb> pchampin, the delay is 15, issues are on, names are on; and the repositories are w3c/
<gb> … w3c/
<gb> … w3c/
<gb> … w3c/
gkellogg: some issues with the GH support bot.
<gkellogg> close w3c/rdf-star-wg#79
<gb> Closed action #79
gkellogg: Minutes were cleaned up for the git-bot confusion by TallTed
pchampin: Will take an action to put the WG repo first.
… github hiccup on actions should be fixed
… transfer of the rdf-tests ongoing
gkellogg: Some activity in the tests so would be good if PRs showed up on the WG dashboard.
pchampin: Will connect the tests repo to the dashboard
Review of pull requests, available at
ktk: From next week, we will include "needs discussion" PRs in the agenda
gkellogg: base direction - have separated out langtag issues. Ready to merge.
pfps: Were we waiting for i18n?
<richard-lea> Excuse me, perhaps lacking a little background stuffs. Wondering that all other repositories starting with rdf- are also currently accounted as contribution from rdf-star? I was assuming rdf-star-wg is the contribition place.
gkellogg: I believe we meet the minimum requirement.
ktk: With the split, I thought we could merge.
pfps: I would prefer to wait for i18n.
<pchampin> https://
gkellogg: We have direction from JSON-LD and we are addressing a concern.
<ktk> richard-lea: I can say something about that in the next issue if ok for you
gkellogg: getting base direction feature in is a starting point. There may be further work as later PRs.
<richard-lea> ktk: Got it. That would be helpful I believe.
pchampin: Link to previous note on the subject for JSON-LD + i18n discussions.
pfps: Concerned that previous work had several solution, one of which was complete.
pfps: There is a complex json-ld datatype includes the ability to reverse the direction of string inside strings.
<Tpt> JSON-LD CompoundLiteral: https://
gkellogg: Two informative solutions worked within RDF 1.1. One a compound datatype, one a compound literal with blank node.
… JSON-LD data model itself would handle it. The compound literal is like reifications - JSON-LD would make it one unit.
niklasl: interested in reification of literals in general.
<richard-lea> AndyS: Is there a github issue where we can see the problem from complex data-type along with simple sample snippets? The i18n in json-ld is exactly mattering in my daily japanese usage context.
niklasl: RDF could define a relationship between simple (current) literals and compound literals.
<pchampin> +1, none of the solutions proposed in the JSON-LD allowed more than setting a *base* direction. None of them allowed to specify direction changes inside the strings, which IIUC is what pfps considers "complete".
niklasl: library context requires structured literals.
… is it possible to discuss this in the WG?
richard-lee: is there a place that discusses the issues?
gkellogg: There were discussion in JSON-LD WG and in JSON-LD spec.
richard-lea: where is the discussion for JSON-LD?
<pchampin> guidance from the i18n group has also been captured here: https://
gkellogg: Issues and meeting minutes - digging needed!
gkellogg: json-ld has a compound value object ... need mapping to RDF.
… compound literals may present some challenges for developers.
AndyS: Within this WG we are not claiming that anything is a complete solution for y18n of text. We look for the minimum to enable people. We have to find out what this minimum is.
… I propose people open issues and describe what a solution might be. Like this we have them side by side.
… otherwise those ideas get lost outside of the discussions here.
gkellogg: There are several issues about text direction.
AndyS: The ones in the wiki were not complete.
… they had the input from all that participated in the discussion.
… We should work on those.
… Some will require a change in RDF, others do not. Compound literals do not.
<richard-lea> It would be also helpful for my side that we can see the discussion point through explicitly opened issues, especially with minimum example code snippet.
AndyS: This will come back to the working group at some point where we have to define how much is in the WGs scope.
ackme
niklasl: I agree with AndyS, I should do an issue about it.
… I have some comments on the JSON-LD approach.
AndyS: the current proposal is not about the JSON-LD datatype
gkellogg: The RDF Concepts PR makes a change to the definition of literals. It adds a base-direction element.
… the JSON-LD mechanisms were a workaround as non of these concepts existed in RDF.
gkellogg: we address the issue fundamentally or defer (which may be forever).
<pchampin> https://
pchampin: Put a link in https://
… I take this as a sign that langtag+basedirection is a minimum and for e.g. HTML literals for compound (displayable) text.
… this is a recent update.
… not advocating the i18n namespace for RDF 1.2 (it was a solution to be within RDF 1.1)
niklasl: we use langtags and get many, many uses. i18n datatype needs to be / not # to allow structure.
<pchampin> s/JSON-LD namespace/KSON-LD i18n namespace
gkellogg: The i18n recommendation is "current best practice". RDF1.2 can pursue a better solution.
<pchampin> +1 gkellogg, I take it as the "direction" (pun intended? :->) to use nothing more
gkellogg: other issue - namespaces - lack of normalization of language tags. (lower case).
gkellogg: ... impacts RDF Canon.
<pchampin> I was mostly considering it as a signal that the PR 48 is on the right path, compared to i18n group's best practices
gkellogg: impact datatype solutions.
pchampin: was responding to PFPS with background and history.
ktk: Are we formally asking for feedback?
ktk: Yes - it's marked with a label as requested
gkellogg: this is a PR for a long time becomes a general block (PR merges etc)
… else we should wait until feed and park the issue
ktk: I will organise discussion with chairs and W3C staff.
ktk: Thanks everyone.
<gb> Issue 100 [not found]
<ktk> richard-lea: w3c/