Meeting minutes
I can scribe today
Scribe
scribe is pfps
Approve previous call's minutes
<ora> https://
ora: any comments about last call's minutes
adrian: ok by me
<gtw> Could we please include the previous week's minutes link in the pre-meeeting email that lists the agenda?
given no objection, minutes are approved
<TallTed> +1 gtw
Agenda
this item is about changes to the agenda
we should spend a little time getting the use cases started
ora: i would like to understand what you are looking for
I would like to see use cases that the working group can use
i.e., specifics about how the use case should be used
ted: use cases provide requirements which can then be checked
I have no objections to suggesting this
enrico: there should be a classification of use cases as well
I'm willing to run a tf on this
<TallTed> `action: nickname to act`
ACTION: pfps to set up tf to get use cases set up
<ghurlbot> Created action #17
ora: I volunteer
gregg: work on text direction should be done at some time
gregg: there is a community group involved
https://
gregg: there are issues involved that I do not have expertise in
gregg: some semantic expertise needs to be involved
pchampin: I can help
pchampin: this appears to be out of scope according to the charter
andys: a backwards compatible solution would be useful
gregg: JSONLD took this up because of input from the internationalization group
ACTION: gregg to initiate discussion of text direction
<ghurlbot> Cannot create action. Validation failed. (Invalid user for this repository?)
ora: should this be of lower priority for now
gregg: there is a feeling that this cannot be left to too late in the process
gregg: doing this early will allow for good input from the community
tallted: what does backward compatability mean here?
andys: there are submissions in the area that are backward compatible
andys: let's not start everything all at once
ora: we might be able to split into task forces, which allows people to concentrate on what they are interested in
ora: smaller groups are more productive
ora: the groups can report back
adrian: there are a few things that are mechanical, e.g., FPWD
adrian: splitting of some stuff will allow people to concentrate
First Public Working Drafts of the "modernized" RDF 1.1 specs: Update
pchampin: we now have respec versions of the specs
pchampin: we need a decision on whether to publish these as FPWDs
pchampin: this starts W3C processes, such as patent review
pchampin: publishing early gives a starting point
andys: I agree
andys: what quality of HTML do we need for FPWD?
<Zakim> pfps, you wanted to emphasize SOTD for this sort of FPWD
pchampin: specprod warnings do need to be addressed
if we publish FPWDs of what we inherit the SOTD should say so
gregg: there is an SOTD already in most documents
gregg: and that should suffice
<Zakim> pfps, you wanted to ask when specprod is involved
gregg: I can help make specprod happy
when do I see output from specprod
gregg: github PRs go through the process
gregg: there are two steps - IPR and respec
if you put in a PR then there should be no problem?
gregg: except for deep links, yes
in essence, checks happen early and we will get notificaitons
pchampin: editors should evaluate whether to publish right away?
I suggest that editors be given direction to try to publish ASAP
tallted: I agree - ask editors to concentrate on getting the documents in shape for FPWD, especially correct & current SOTD
gregg: timelines for RDF and SPARQL documents are offset so they might happen on a different timeline
gregg: the RDF documents appear in good shape
andys: other WG members can submit changes
<Zakim> pfps, you wanted to ask what approval process should be like
what is expected for a PR to be merged
gregg: in RDF canonicalization there was a list of people automatically requested to review a PR
gregg: so PR proposers should ask for reviews and after a suitable time period merge even if there are no reviews
pchampin: the editors should decide on the process
ora: talk about this next week
andys: what is the result?
gregg: resolution on whether to publish
andys: I want both RDF and SPARQL documents to have FPWD at the same time
ACTION: pchampin to coordinate on proposed resolution on FPWD
<ghurlbot> Created action #18
<AndyS> (some SPARQL documents)
RDF vs. RDF-star conformance ("Weak vs. strong", ...): Approval?
ora: this was discussed earlier
ora: I think this is a good idea
I'm not opposed but the result of the working group might not need this distinction
For example, suppose the WG decides that quoted triples only require changes to surface syntax
ora: if so then the decision is moot, but a decision now would alleviate some concerns
<Zakim> pchampin, you wanted to point out that turtle parsing would still need a change
pchampin: surface syntax is a change but there still might be a difference between weak and strong compliance
andys: looks like a good idea in principle
andys: but this might affect decisions made in the future
andys: and using this to drive future decisions is bad
gregg: syntax changes hit most specifications
gregg: the WG hasn't decided on syntax
gregg: level of conformance decisions might make it too easy to dismiss concerns about technical issues
+1
<Zakim> pchampin, you wanted to mention "allowing new features" / living standard
pchampin: the WG process can decide to permit later streamlined additions of new features
pchampin: the WG should start to think about this option
ora: we can't make a decision today, but please think about it
ora: having this decision in place would help in technical discussions
andys: would a written proposal help?
ora: if distributed beforehand, yes
antoine: the proposal came from elsewhere
ora: antoine, do want us to work on a proposal
antoine: yes
ACTION: ora to work with antoine and others to come up with a proposal for weak and strong compliance
<ghurlbot> Cannot create action. Validation failed. (Invalid user for this repository?)
<ktk> For the meeting minutes: Souri excused himself for todays meeting
ghurlbot, ora = @rdfguy
<AZ> one way is to change "ora" to "AZ"
ACTION: rdfguy to work with antoine and others to come up with a proposal for weak and strong compliance
<ghurlbot> Created action #19
<TallTed> we might consider levels like SQL conformance (Entry, Intermediate, and Full)
<AndyS> Conformance email is https://
<AndyS> (W3C archive search does not find it when searching for "weak")