Meeting minutes
Announcements and newcomers
new member: Julián
pchampin: I will take some time off next week, will not be on next call
pchampin: who will be the chair?
pchampin: propose we skip next week
pchampin: new pull request from gkellogg
pchampin: Trig-star
gkellogg: still some questions to be worked out
gkellogg: e.g., ordering
pchampin: examples in abstract syntax is a good idea
andys: prefer Turtle* first
gkellogg: will do a PR for ordering
Action: gkellogg to reorder the concrete sections: Turtle-star, TriG-star, N-Triples-star, N-Quads-star
<Zakim> AndyS, you wanted to say that there is a TriX-star implementation (!!)
andys: I did a TriX-star implementation, for no reason whatsoever
<gkellogg> I updated my TriX implementation too :)
Open actions
pchampin: no open actions
publishing a new draft
<AndyS> The 2nd draft discussion -- https://
pchampin: canonicalization will probably not make it to the next draft
pchampin: we discussed that a new draft sooner rather than later would be a good thing
pchampin: publish often and early
pchampin: some things are pending...
pchampin: 5 PRs
pchampin: some have no impact on the draft
pchampin: test suite
<pchampin> https://
pchampin: does not stop us from publishing
(audio weirdness, did not capture everything...)
now fine again...
<pchampin> https://
pchampin: long standing PR: clarification of SPARQL functions
james: that's what I wanted to add
pchampin: olaf wanted to remove some examples
pchampin: recommend merging anyway
<pchampin> https://
pchampin: recent PR: extending the overview with examples using annotation syntax
pchampin: propose we leave a few days for people to react, merge next week
pchampin: after these merges we should publish
<pchampin> PROPOSAL: merge PR 129 and 155 after a few days, and then release next public draft
<pchampin> +1
<william> +1
<gkellogg> +1
<ora> +1
<james> +1
<rivettp> +1
<AndyS> +1
<TallTed> +1
<Julian> +1
pchampin: reminding we are not a formal group, wrt. voting
Resolution: merge PR 129 and 155 after a few days, and then release next public draft
andys: what is the most pressing issue to close?
pchampin: I will be back the week after next
pchampin: several active issues
pchampin: we are in pretty good shape overall
pchampin: but still: introducing a new IRI
pchampin: mime-type
pchampin: do we want to include something about SHACL, possible SHEX?
andys: I think no need to do that
andys: once there is a CG report (our target), then the SHACL group can react
andys: similarly for SHEX
gkellogg: we did not address JSON-LD either
andys: label open issues as "discussion items"...?
pchampin: Notation3, semantics (at least) belong there
<pchampin> STRAWPOLL: we won't include anything in our report about SHACL not SHEX
<gkellogg> +1
<william> +0
<james> +1
<ora> +1
<AndyS> +1 (better to come from those communities)
<Julian> +1
<rivettp> I think we should at least mention SHACL and OWL with an outline of possible impact
<pchampin> +1
<rivettp> -1
pchampin: I did not mean to not mention at all
pchampin: the idea is not to ignore, we can give some "leads"
rivettp: should be fine
<AndyS> FYI: OWL-star https://
<rivettp> +1
pchampin: next public draft is very close to a final report
pchampin: editorial changes notwithstanding
RDF-star and dataset canonicalization
pchampin: this was raised by gkellogg
pchampin: there is a W3C WG charter proposed, linked data signature
pchampin: standard way of signing RDF datasets
pchampin: hence canonicalization
pchampin: question was raised about RDF* during preparation
pchampin: RDF-star included in the proposed charter
pchampin: understanding that RDF-star will not be a Rec by then
(thank you AndyS)
pchampin: dataset defined in terms of triples, nothing about embedded triples
pchampin: clarification is needed
gkellogg: canonicalization is challenging (math proofs), extending to RDF-star could be problematic
gkellogg: RDF-star dataset transformed to RDF dataset could be signed
gkellogg: but now we would have two versions of the same
gkellogg: let's not use language that restricts our work too much
andys: how about a short section about principles (embedded triples, etc.), any future work on RDF will need to deal with these
andys: that is, set requirements rather than offering solutions
gkellogg: they may not heed any of that
gkellogg: solution may involve introduction of a new vocabulary
gkellogg: make it possible to do a reverse transformation
andys: RDF-star system understand embedded triples natively, this may be a problem
pchampin: hidden IRIs...
andys: my point was that they are not isomorphic
gkellogg: canonical does not have to imply isomorphic
andys: what if two different things have the same canonicalization, because we missed something?
andys: you may need to know that something was originally RDF-star
<gkellogg> Link to RDF C14N draft: https://
pchampin: introduce reification predicates only for this purpose?
pchampin: an RDF graph using these would be identified as coming from RDF-star
gkellogg: canonicalization algorithm should introduce extensible steps [?]
gkellogg: it is not our job to solve this, but make it possible for future groups to solve it
gkellogg: this is not simple to implement
gkellogg: math proof is required, changing the algorithm would invalidate the proof
andys: IRI spec explains how to turn an IRI into a URI
pchampin: what do we do after publishing the 2nd draft?
andys: mention it in the charter...
andys: we will not be recommending changes to the algorithm
gkellogg: similar to n3 and lists
pchampin: we will liaise at some point
pchampin: not much more we can do
pchampin: no time to discuss media type this time
open-ended discussion
gkellogg: namespace for hidden triples?
pchampin: type for hidden triples?
andys: new extension namespace for all groups to use
andys: "rdfx"
pchampin: temporary use?
andys: that is the idea, but reality may be different
andys: creating things is easy, getting rid of them not so much
pchampin: we could create a temporary RDF-star namespace, just as easy to fix (or not)
pchampin: put a time extent on these
<AndyS> e.g. https://
andys: what's under "ns" at W3C?
ora: I don't understand the need for that NS
… namespaces are cheap
… the essential thing is that they must be unique
… This notion of shared namespace is a misuse of the concept.
… It may create clashed, which namespaces were invented to prevent.
<rivettp> I think rdf namespaces are a mess because we have too many - people don't know when to use rdfs vs rdf
<william> yes, indeed
gkellogg: there is a difference between something that is eventually meant for, say, the RDF namespace, as opposed to something that remains separate
<william> thanks!
<gkellogg> We need a CG to discuss transitional IRIs :)
bye