Meeting minutes
Announcements and newcomers
Daylight Saving Time (US) and Summertime (EU)
pchampin: switch happens at different times in the US and in Europe
pchampin: what would be the reference time zone?
<TallTed> typical practice for w3 work is Boston/New York, but it won't make a lot of difference for me
<TallTed> US would be an hour later (as it would be noon where it is now 11am)
<pchampin> if we stick to UTC: https://
gkellogg: W3C uses Boston time
pchampin: using European time, would be noon for Boston, 9 am for SF
pchampin: gkellogg's argument is valid, though, not to interfere with other W3C meetings
<TallTed> this just impacts the next two weeks, correct?
pchampin: yes
<thomas> gregg has the only argument, so why not take taht?
pchampin: propose to stick with US time
<pchampin> PROPOSED: stick to US time to avoid conflict with other W3C meetings
<pchampin> pchampin: +1
<thomas> +1
<gkellogg> +1
+1
<TallTed> +1
<william> +1
<olaf> +1
<rivettp> +1
<AndyS> +1
<james> +0
gkellogg: strong push in the US to eliminate DST
pchampin: we will stick with the US time
Resolution: stick to US time to avoid conflict with other W3C meetings
pchampin: next week 1 hr earlier for Europeans
SPARQL-eval test suite
<pchampin> PR: https://
andys: no such things as finished test suite
andys: generally good coverage now
andys: syntax tests updated
pchampin: we must reach out to implementors
<gkellogg> My implementations pass all the tests.
andys: I would like to merge now
<pchampin> PROPOSED: merge PR 114 befor advertising the test suite to implementers
<gkellogg> +1
<pchampin> +1
<TallTed> +1
+1
<AndyS> +1
<thomas> +1
<james> +1
<olaf> +1
<rivettp> +1
<william> +
<william> (sorry)
<william> +
<william> +1
Resolution: merge PR 114 befor advertising the test suite to implementers
<william> (numlock was off :-)
gkellogg: we might consider publishing an implementation report early
gkellogg: I have tooling to check
<pchampin> example: https://
andys: if we get good coverage we should publish
pchampin: sounds like a good idea
pchampin: will add a link to the spec
<TallTed> EARL is common (probably best, probably not only) practice for implementation reports these days.
<TallTed> per-test results are optimal for CR->PR->TR, and probably also for CG->Report->WG
Action: gkellogg to make a PR for the implementation report
pchampin: we should make an announcement
andys: could someone check the HTML manifest?
gkellogg: to check that the HTML manifest covers all?
andys: yes, the HTML manifest is generated from Turtle
andys: set of tests does not prove your implementation
pchampin: we should be careful to avoid any statements about completeness
pchampin: this is work in progress
pchampin: raise awareness on the mailing list
pchampin: any other channels?
andys: give people the chance to look before we go to a wider audience
<james> i do not necessarily intend to exercise the test suite before the report is complete
gkellogg: other groups' impl. reports are not necessarily frozen, late entries are accepted
pchampin: nothing is frozen
pchampin: why not use it early?
pchampin: I will email the list
pchampin: there are discussions on the list about function descriptions, should we discuss?
james: we can use the list
Define a URI for the class of embedded triples
pchampin: what namespace?
not ideal to proliferate namespaces
changing an IRI later does not work well
we do not, however, have the authority to change RDF
ora: why is proliferation of namespaces bad?
… easy to create an RDF-star namespace
andys: how much would go to a new namespace?
andys: if it is very few things, might not be worth it
gkellogg: comes down to the question about the purpose of this CG
gkellogg: if we are creating a new spec, makes sense to have a new namespace
gkellogg: if it is to advise other groups, then maybe not
gkellogg: if there is going to be a new RDF WG, then our work is considered an experiment
gkellogg: we can invent new IRIs, we just don't have the authority change RDF, etc.
thomas: semantics not stable
thomas: so perhaps not a good idea to use the RDF namespace
thomas: more prudent to use an RDF* namespace
pchampin: the whole spec is unstable
pchampin: nothing will be fixed until we reach a stable state
thomas: semantics unproven for now
ora: the rdf vs.rdfs issue is historical
… there was 2 different groups
… retrospectiveley, it was unfortunate
andys: missed thomas' point: what is tied to semantics
andys: i am looking at the effect on users
andys: I suggest we say "we propose that..."
gkellogg: RDFa added stuff
ora: RDF namespaces are fixed
gkellogg: any WG is authorized to update namespaces
gkellogg: CG is input WGs
ora: I doubt that it's true that any WG is authorized to change the RDF namespace
gkellogg: we did in the JSON-LD WG, figured this out with Ivan Herman
<TallTed> WGs can change W3 namespaces, *upon approval by W3 Management*, which is not automatic but is typically granted with suitable justification from the WG
gkellogg: we did discuss whether the JSON datatype should be in the RDF NS
ora: feels strange; changing the NS is invalidating the spec
AndyS: this is an addition, not a change
ora: but implementation may enforce the notion that RDF and RDFS namespaces are fixed
TallTed: enforcing something that is not fixed is an implementation error
gkellogg: JSON-LD process was to ask for comments from the community first
gkellogg: very little feedback
gkellogg: no evidence of implementations breaking
thomas: what if semantics change? We define a new term/
gkellogg: RDF 1.1 does not have plain literals
william: Notation3 CG made the decision to reuse old namespaces
william: we did not want to add namespaces
william: TimBL said to go ahead
<pchampin> STRAWPOLL: put our IRI(s) in the RDF namespace
<gkellogg> +1
<pchampin> +1
-1
<rivettp> +1
<james> +1
<thomas> -1
<AndyS> +1
<william> +0
<olaf> +0
<TallTed> +0
no consensus
pchampin: polite thing to do is to seek broader feedback
andys: if something is controversial it is a good idea to make sure people pay attention
andys: (anecdote about John McCarthy)