Meeting minutes
ora: chairs propose timeboxing items to 20mins.
… can still be less
… idea is to at least take the temperature
… this is an experiment
… comments?
ora: (no comments)
Consider reintroducing property paths {x,y} syntax dropped in SPARQL 1.1 1
tallted: delay to future work
<pchampin> Tpt: I'm confused also because this is much less an errata than the EXIST feature, on which we are having scope-discussion
AndyS: agree to postpone
<pchampin> + 1 gkellogg
gregg: 1.2 specs marked new features ... so not 1.3
ktk: At this point we say "later" and no "when"
ora: OK?
(agreement by silence)
<gkellogg> +1 to future-work.
AndyS: I will clear-up the GH issue after the meeting
<ora> PROPOSAL: postpone to future work, after main RDF&SPARQL 1.2 are complete
<pchampin> +1
<AZ> +1
<ora> +1
<gkellogg> +1
<TallTed> +1
<Tpt> +1
<tl> +1
<doerthe> +1
<AndyS> +1
<james> +1
<gtw> +1
<ktk> +1
<olaf> +1
<niklasl> +1
<gb> Issue 41 Allow dataset formats to be valid in LOAD with no INTO (by afs) [Errata] [needs discussion] [spec:enhancement]
pchampin: (wrong link)
<gkellogg> w3c/sparql-update#147
<gb> Issue 147 not found
<gkellogg> w3c/sparql-query#147
<gb> Issue 147 consider reintroducing property paths `{x,y}` syntax dropped in SPARQL 1.1 (by TallTed) [ms:future-work] [needs discussion] [spec:enhancement]
RESOLUTION: postpone w3c/sparql-query#147 to future work, after main RDF&SPARQL 1.2 are complete
Drop the requirement to support ill-typed literals with recognized datatype IRIs 2
ora: from outside the group
ktk: last time (3 weeks ago), .... now we have a proposal.
<ktk> w3c/
<gb> Issue 60 Drop the requirement to support ill-typed literals with recognized datatype IRIs (by wouterbeek) [needs discussion] [spec:enhancement]
james: as a matter of process, why is this being worked on?
pchampin: W3C hat off -- while there was no errata, it seems a low hanging fruit and some existing implementation implement "should" - codify existing practice.
<pchampin> I still need to write down an answer, but I have some data about that
james: I asked for a catalog of implementations
pchampin: I have data
james: I am concerned because of interoperability
ora: table until next time (US "table" meaning)
gkellogg: it relates to "supported datatypes" and hence for the instance and interoperability is not related to "supported datatypes"
… could label tests
tallted: not an erratum until previous work reviewed
pchampin: not all system do the same
… does not impact interoperability because ill-typed literals do not have a meaning
… to ted - datatype are not opaque in the same way as general IRIs
james: could interpret it as an errata in the other direction
… lisp has "undef" clauses in the spec
<pchampin> +1 to provide a way for implementation to be explicit about what they are doing with ill-formed literals
ora: suggest we see what data pchampin has collected
<Zakim> TallTed, you wanted to ask about application-specific datatypes, which might be subtypes (or supertypes) of xsd
TallTed: at the moment, anyone can define a datatype
… works until it encounters a system that drops them
<niklasl> https://
AndyS: the text refers to "recognized datatypes" that a system must declare.
… So I don't think that TallTed's concern will happen.
… I don't know systems that declare the datatypes they recognize.
<ora> STRAWPOLL: table (@en-us) until we have seen pchampin's data
<gb> Issue 60 Drop the requirement to support ill-typed literals with recognized datatype IRIs (by wouterbeek) [needs discussion] [spec:enhancement]
<ora> STRAWPOLL: table (@en-us) w3c/
<gtw> +1
<ora> +1
<gkellogg> +1
<tl> +1
<pchampin> +1
<ktk> +1
<Souri> +1
<james> +1
<niklasl> +1
<TallTed> +1
<AndyS> +1
<doerthe> +1
<william_vw> +1
<AZ> +1
<eBremer> +1
<Tpt> +1
<olaf> +1
RDF graphs with value-space literals 3
AndyS: I think we can't do it. It needs careful thoughts and may have many visible impacts.
… It may be valuable, but needs much more work.
AndyS: don't do it in RDF 1.2 - need significant preparation
gkellogg: similarly - we should postpone.
… wait for when pfps attends
ora: call for support to work on it (silence)
pchampin: pfps away next week as well
gkellogg: we have a pause label
ora: leave as-is
Allow dataset formats to be valid in LOAD with no INTO 4
<gb> Pull Request 46 LOAD RDF document clarification (description section and definition section) (by afs)
AndyS: At the time SPARQL Update was written, it worked only on graphs. It's undefined on how to load documents that describe datasets.
… The PR says that LOAD <doc> loads to the dataset, so that quads in TriG would create a SPARQL dataset.
… There are more complicated things, such are re-mapping graph names, but that is not covered in this proposal.
… Some formats it is difficult to know if it encodes a graph or a dataset (e.g., JSON-LD).
… It says you need to generate an error if there are any quads, otherwise, it would go into the target graph.
ora: If I were loading N-Quads, and it specified the graph to load into, would it be an error
AndyS: Yes, that would be an error. If there is no graph name, it would go into the target graph.
pchampin: Could we say that the "INTO" is where default triples go? And other triples go into their specified graph.
… (Verified Credentials use cases).
… Blank node graph names.
AndyS: There are systems that would just use the default data, and they would not be compliant.
… The PR is just addressing the case on when there is no "INTO" clause.
… Use cases with blank nodes are interesting, as are renaming use cases, but that is not the target of this PR.
… Please raise issues for other use cases.
… So, LOAD <...> loads the dataset.
james: How does this align with the graph-store protocol, which is also underspecified. Can they be aligned?
… Having a matrix for the variants would be helpful information, even if incomplete.
… It's hard to understand the affect as is.
AndyS: The graph-store protocol is not quite the same thing, as you need to explicitly name the target.
… There is another protocol for loading quads into a dataset: HTTP.
… You can argue that that is loading the dataset.
… We could add an informational note about this, but right now, I suggest we focus on the LOAD use case.
james: It's odd that that the graph-store protocol is not sufficient. I think it's inability to handle other graphs as an erratum.
… I consider the issues to be the same, they both have to do with quads going into a dataset.
ora: Nothing prevents us from fixing the graph-store protocol from being inline with this. Do you object to fixing this right now?
james: I'd like to know specifically where we're going to understand the expected behavior, as these are interrelated.
… I'd like to see a more transparent description of what should happen.
AndyS: Perhaps james can read the definitional part of Op Load. Please make a separate proposal, but people actually need to work on it.
ora: I suggest we fix LOAD now and consider a matrix approach in the future.
PROPOSAL: Continue with https://
<gb> Issue 41 Allow dataset formats to be valid in LOAD with no INTO (by afs) [Errata] [needs discussion] [spec:enhancement]
<ktk> +1
<niklasl> +1
<gtw> +1
<gkellogg> +1
<pchampin> +1
<ora> +1
<AndyS> +1
<james> +1
<Souri> +1
<Tpt> +1
<william_vw> +1
<tl> +1
<olaf> +1
<AZ> +1
<TallTed> +1
<doerthe> +1
<eBremer> +1
RESOLUTION: Continue with https://
<gb> Issue 41 Allow dataset formats to be valid in LOAD with no INTO (by afs) [Errata] [needs discussion] [spec:enhancement]
james: I will add a matrix to the issue to see if I have understood correctly.
<gb> Issue 130 vocabulary to refer to the individual nodes in a triple term (by rat10) [discuss-f2f]
<gb> Issue 130 vocabulary to refer to the individual nodes in a triple term (by rat10) [discuss-f2f]
<Zakim> tl, you wanted to ask about status label of issue #130 <w3c/