Meeting minutes
Approval of minutes from the last two meetings: 1 , 2
Approval of the minutes
ora: any concerns?
<pfps> both minutes look fine by me
<ora> PROPOSAL: Approve minutes
<ora> +1
<AndyS> +1
<ktk> +1
<olaf> +1
<rubensworks> +1
<niklasl> +1
<TallTed> +1
<tl> +1
<pfps> +1
<gtw> +1
<fsasaki> +1
RESOLUTION: Approve minutes
Meeting/no meeting on Ascension day
Meeting/no meeting on Ascension day
<pfps> My understanding of Catholic mythology is a bit lacking. What date is "Asenscion day"?
ora: the idea is to cancel next weeks meetings
<ora> PROPOSAL: Cancel next week's meeting
<TallTed> a little firehose for the curious... https://
<ora> +1
<niklasl> +1
<olaf> +1
<ktk> +1
<tl> +0
<gtw> +0
<doerthe> +1
<fsasaki> +0
<TallTed> +0
<rubensworks> +1
<pfps> 0
<AndyS> 0
<pfps> not even new years?
<pfps> and boxing day?
Adrian: topic on calendar and if I dont hear anything by monday I would propose to cancel it then
RESOLUTION: Cancel next week's meeting provided nobody contacts Adrian by Monday
TPAC: Deadline until May 20th
TPAC: Deadline until May 20th
Adrian: deadline May 20th
ora: TPAC in California
<gtw> TPAC date?
ora: we can have remote participation
<gtw> https://
<AndyS> TPAC -- 23-27 Sept
ora: end of september.... i think we should do it. what do other people think?
ora: provided W3C gives charter extension
<TallTed> I'll be remote only, but in favor of the extended session
<niklasl> I'd strive to attend at least virtually (in spite of timezone diff)
Ora: I will try to be there in person
<Souri> +1 may be remote, not sure
<olaf> I wouldn't be able to attend. We have an EU project meeting at the same time.
<AndyS> Will attend - remote or local TBD
<ora> PROPOSAL: Register for TPAC
<tl> will probably attend, probably remote
<ora> +1
<gtw> +1
<ktk> +1
<tl> +1
<olaf> +0
<AndyS> +1
<Souri> +1
<fsasaki> +0
<doerthe> +0
<rubensworks> +0
<niklasl> +1
ora: Let's do it
RESOLUTION: Register for TPAC
<TallTed> +1
Proposal for next week's discussion
Proposal for next week's discussion
AndyS: 2 morning slots instead of full day...
<eBremer> s/slows/slots
ora: we may not have meeting but if someone wants to lead that meeting....
ora: have focused meeting two weeks from now?
<tl> +1
<Souri> +1
<niklasl> We could keep the cycle if we have two consecutive focused meetings?
<ora> PROPOSAL: Shift meetings and have a focused meeting two weeks from now
<niklasl> +1
<ktk> +1
<TallTed> +1
<gtw> +1
<doerthe> +1
<olaf> +1
<fsasaki> +1
<rubensworks> +1
<AndyS> +1
RESOLUTION: Shift meetings and have a focused meeting two weeks from now
ora: we should think of a topic
… one possible discuss two profiles Enrico submitted
… any other ideas?
TL: discuss singleton properties
ora: we could throw that into the mix for sure
… singleton properties have come up in the RDF community before
… has not gone anywhere
TL: Okay
Ora: let's talk about it
… the topic for the meeting in 2 weeks would be profiles
… and possibly singleton properties
RESOLUTION: Topic for next meeting: profiles + (potentially) singleton properties
Review of open actions
Review of open actions, available at 3
<tl> my proposal is to discuss a combination of RDF-star triple terms as the syntax and singleton properties as the semantics. but let's wait how the discussion on the mailinglist evolves
Review of pull requests, available at 4
Ora: and thomas, yes, what you put in chat is fine
<niklasl> +1
Ora: What are we gonna do about the json thing?
pfps: there are substantive problems in the proposal...
… and they have not been addressed...
… they're unresolved questions....
… i would say get rid of RDF:json
Ora: interesting idea of course
… JSONLD folks took a very practical approach....
gtw: they were the ones who defines it
… thats seems like makes for moving it a non-starter
pfps: we have no obligation to talk about it...
… there are firm definitions of what it takes to be a RDF data type...
AndyS: it's already been published into the RDF name space, so I think we'll have to keep it
Ora: does anyone know if this has cause problems?
<AndyS> https://
pfps: not the right question to ask
<Zakim> TallTed, you wanted to wonder whether it would be sufficient to enumerate the issues we see as unresolvable writ large, and therefore are to be handled thus-and-so
pfps: can there ever be any problems that would cause security things to break
TallTed: that becomes something to put into security considerations...
pfps: there are a bunch of unspecified things
TallTed: log issues with those other specs on particulars. this is a large issue as its written for us
… I dont think we should be expected to find all the problems in the other specs...
pfps: The question is whether jcs has an internal error
TallTed: they have a strong errata handling mechanism in IETF
pfps: I can try poking them informally...
Ora: I have friend who was in IETF if yours doesnt work
Ora: if we cant get anyone to fix their documents, what is the best way for us to resolve this?
… we just put some nasty language in our spec
TallTed: It doesn't have to be nasty...
ora: prudent course of action is to try to influence the others without killing ourselves
AndyS: ...security issue. The obligation is to report it
Ora: we absolutely should report...
AndyS: making a external claim on someone elses matarial that there is a security issue is a very serious step to take
TallTed: If we're restating things. then we have a stronger obligation to figure out why a should is a should and not a must
… because there are legitimate reasons to do that
… we can make a judgment call as to whether we want to make it a requirement a must in our spec for doing this thing
ora: lets see what happens when Peter pokes the IETF people
TallTed: it is also legit to make that an open issue on what we're doing and put it out for wider community input
<doerthe> I will read
<AZ> once PR 48 of rdf-semantics is merged, we can close issue 46
ora: out of time
… no time for the issues
<eBremer> s/not no/