Meeting minutes
<Tpt> (might have to drop early
Scribe: TBD
Approval of last week's minutes: 1
AZ: my acronym is used, but I was not present
dominik_T: same case for me
pchampin: maybe we didn't kick out some agent
pchampin: can propose to approve pending fix of presence
<ktk> PROPOSAL: Accept the minutes, pending the removal of presence for AZ & Dominik_T
<gkellogg> +1
<ktk> +1
<pfps> +1 with the change
<AndyS> +1
+1
<TallTed> +1
<doerthe> +1
<pchampin> +1
<Dominik_T> +1
RESOLUTION: Accept the minutes, pending the removal of presence for AZ & Dominik_T
<enrico> +1
<ktk> Zakim: close item 2
Update on Use Cases
pfps: not much to report
… several use cases are progressing. one new one I haven't got to.
… if you have use cases, please add it.
… Ted said he couldn't edit wiki entries. That's because permissions are set differently. pchampin?
… you can put PR against the wiki as well.
AndyS: I tried to track the docs for that. Seemed to say you couldn't do that.
ACTION: pchampin to ensure that anyone in the WG can edit the UC wiki / make PR
<ghurlbot> Created action #67
pfps: let me try and find it.
pfps: at the bottom of this page...
<pfps> Look at w3c/
pfps: some permissions have to be changed.
pchampin: I have an action to look at this. Probably only the editors could make changes to repos.
… for use cases, arguably that should be different.
pfps: UCR is probably locked down more strongly than others.
AndyS: I can't see anything saying you can do PRs. What am I missing?
pfps: [quotes from linked page]
AndyS: that's not a PR.
pfps: you could create a new branch. should be able to do PRs.
AndyS: github adds another layer on top of the PR mechanism. Have found pages that say you can't do that. No machinery for wikis.
pfps: I'll check it out.
ACTION: pfps to check out PRs against GitHub wiki pages
<ghurlbot> Created action #68
AndyS: pfps, do we have reasonable coverage at the moment?
pfps: no.
… we have one which is very syntactic. several are semantic. don't really have a provenance use case.
AndyS: syntactic is add/delete triples?
pfps: yes.
AndyS: the other one that came up was danbri's triple occurences.
pfps: we don't have a UC for it.
… all of the semantic ones really seem to be about occurences. anything with events requires triple occurences.
… when you take an event that has multiple arguments, project down to 3 args, you invariable end up with many-to-one mapping.
… you have to back off from the triple or things get conflated.
… depends what you mean by occurence.
ktk: do we need to ping people again to add provenance one?
pfps: on my list. trying not o add too many use cases so I can remain responsive.
… I'll try to ping more people. Tried to pick ones which were easy (but was wrong). Will try to pick prov-related ones.
ktk: If you need more support, let us know.
pfps: CIDOC-CRM is really complicated. I think I know what they wanted now.
… took a lot of back and forth.
Update on Semantic TF 2
enrico: the plan was to have small schema that explains all possible variation of behaviors.
… of use cases. how many variations you can have.
… so far we're not concerned with formalizing semantics for each.
… just to have exhastive list of behaviors.
… for example, the case pfps mentioned would be captured by one of these variations.
… again by superficial look, what pfps is saying is correct. most UC fall into two major cases.
pfps: there was an action on me to add to terminology. I have a PR in. there's been some comments that I have to figure out what to do. in-progress.
Text Direction
[discussion about agenda management]
<gkellogg> w3c/rdf-concepts#48
<ghurlbot> Pull Request 48 Add text direction as a fourth element of literals. (gkellogg) i18n-tracker, needs discussion, spec:substantive
gkellogg: this was my proposal. PR to support initial text direction.
… agreed several meetings ago that we could work on this.
… there's a fair amount of discussion in PR about terminology.
… we determined that correct term is "base direction". unicode uses that also.
… question about how do we characterize literals including initial text direction.
… one being to add additional facet to rdf:langString where there's now a text direction element in addition to lang tag
… another option would be another type of literal dirLangString
… would semantically differentiate the two. ltr, rtl, none for langString; only two options for dirLangString.
… variety of references in there for why this is important.
… calls for this for some time.
ktk: asking for reviews of PR?
gkellogg: questions about how we want to review literals. is adding another concept beyond lang-tagged strings a little conceptual overload?
… they are virtually the same thing.
… is it semantically clearer with different datatypes and terminology?
pfps: I'm still confused what requirement this is meeting.
gkellogg: if you look at documents on text direction in unicode, there's description on the problems with how to start off displaying text (ltr, rtl).
… cannot be determinied by unicode codepoints/characters.
… cases highlighted without providing metadata on how to start, it will get it wrong.
… this adds metadata. in html this is done with a dir attribute interpreted as how to start the presentation.
… as you noted, it's not completely adequate since direction can change within a string.
… at that point, we're beyond strings into structural elements. html would solve this with spans each with its own direction.
pfps: I get all that. I don't understand what good a partial solution is.
gkellogg: I think it is a complete solution for how to display strings. Where string is a sequence of codepoints.
… not trying to solve a markup problem where you can compose arbitrarily complex document.
… I invite people to look at referenced documents.
… we had disussions with i18n team and community.
… several people including pchampin and ivanh spent a lot of time on this in json-ld phase.
pfps: this is something to keep i18n team happy?
<pfps> I dispute that initial direction solves string display. There are strings that require in-line metadata.
gkellogg: not being able to support directional text is an i18n ... [?]
pchampin: yes, you could put it like that. it's to make the i18n people happy.
… this is not a full fledged document format.
<pfps> if this is something to satisfy the i18n requirements, then we should get their approval before this is merged
pchampin: given language strings are human-oriented and meant to be displayed, good practice is to make this metadata available for them as well.
… the first proposal is to have two distinct datatypes langString with optional direction, and dirLangString with mandatory direction?
gkellogg: not entirely. in first option, we'd use langString with base direction as element.
… it's one possible value for that would be "no direction".
<pfps> What I don't understand is there are already two ways to provide full information about text direction - rdf:HTML and the i18n types from JSON-LD
pchampin: I'm not a big fan of multiplying datatypes.
… could imagine instead of no direction, the absence of direction could be...
gkellogg: I think it was absence. would expect it to inherit direction in html.
<Zakim> TallTed, you wanted to say relatively simply, this is movement toward better internationalization of RDF. still imperfect, but vastly better than today.
TallTed: answering pfps' question, it improves our i18n which is a generic reuqirement of all w3c documents.
… we need to do what we can to make those things better.
… as there are scripts that go both directions, this is needed.
… also vertical scripts, but don't think they are manditorially so.
… might be another question for i18n group.
… we have reasonable solution right now for rtl and ltr.
Review of open actions, available at 3
w3c/rdf-semantics#30
pchampin: I reached out to some people in w3c. Took opportunity to have a closer look at the issue.
[what issue?]
… go incrementally with this. Tweak one parameter at a time.
… discussion is all over the place because PR makes a lot of subtle changes.
… think we should aim to tidy the HTML itself. We are inheriting rather old HTML.
… align more with respec stylesheets might solve problems. Once we have clean html, we can optimize css.
… I'm assuming that's what w3c colleague will tell use.
<ktk> it's this issue w3c/
ktk: issue on strong compliance. needs discussion.
w3c/rdf-star-wg#19
AZ: have not had the time to read the last comments on the 'compliance' issue #19
<ghurlbot> Action 19 work with antoine and others to come up with a proposal for weak and strong compliance (on Antoine-Zimmermann, rdfguy) due 16 Feb 2023
ktk: any other actions? issue 13 is complete. close it?
<AZ> s/compiane/compliance/
pchampin: we can resolve it. I reported on that last week.
ghurlbot, close #13
<ghurlbot> Closed action #13
pchampin: reporting on the #55 issue. few documents that are not published yet.
… everything except for trig.
<ghurlbot> #55
pchampin: every merged PR leads to new publication of new draft.
ktk: issue 55 in rdf-star-wg
<TallTed> s/compliane/compliance/
Review of pull requests, available at 4
gkellogg: the PR on trig for quoted triples.
… I think we can merge that.
<ktk> w3c/
gkellogg: will test out echidna publication.
ktk: no comments. think this is "go".
<TallTed> s|s/compliane/compliance/||
<TallTed> s|s/compiane/compliance/||
Discussion on named graphs 5
ktk: continuation of what we started last week.
… not named graphs as I learned. "context".
AndyS: no, not "context". That is not an accurate description of how it came about.
… that was one of the inputs to the WG.
AndyS: another confusion is whether they are really talking about graph literals vs. named graphs.
… a term in the RDF graph could be another graph (n3-style)
… don't think treating singletons in graphs is the same as talking about triples.
… not convinced there is a complete answer that excludes quoted triples.
pchampin: I'm still unsure what we should do. +1 to what AndyS said. Difference between named graphs and graph literals.
… I'm wondering if we should make some statements from WG, what form that should take (blog posts?).
… enough documents to work on.
… still people are nagging us about this.
… there's some consensus in the group. we seem to go in the same direction.
… what would be the best way to capitalize on this group knowledge? make it available to the rest of the world.
AndyS: we do have RDF-new.
… I'm not sure it's that beneficial to go that way. It's got to explain what's new. If it becomes a defense of it, doc doesn't actually help new people.
… We can make a statement. I don't think that will change the situation a great deal.
… It's easy to pick weaknesses about any approach that tries to be a simple step forward.
… technologies have potential to make things to work, don't know what it would look like in reality, whether it gains acceptance.
<Zakim> pchampin, you wanted to propose that we could spin in a non-defensive way
pchampin: rdf-new could be a place where we could write something.
… could spin it as not defensive.
… we should be careful not to be too defensive on proposals.
ktk: easiest way to say something is the mailing list.
… regarding living spec, a blog is a bit more formal.
… rdf-new would be even more formal.
Any Other Business (AOB), time permitting
ktk: ora remarked in two weeks is the week of july 4th. holiday in the states. proposed we might cancel.
gtw: I will be here.
<pfps> The holiday is Tuesday, so people would have to take a whole week off for the meeting to impacted.
gkellogg: I will be scuba diving.
pfps: I'm in Canada.
pchampin: there are enough people not impacted that we justify keeping the meeting.
gkellogg: trig did updated, btw.
<TallTed> fwiw, I'm fine to meet on the 6th
<ktk> looks good tnx