Meeting minutes
RDF Concepts 1
ktk: I have seen much feedback on the mailing list
AndyS: we can not address each item individually. We need to identity highlights, so that we can progress on github.
<pfps> sorry, talking to a device with no mic
<pfps> go on without me for now
ktk: last time we agreed to review RDF-Concept and identify what we thought were the blockers to go to Candidate Recommendation
pfps: to determine the blockers, what's our requirements for CR?
… We can go to CR with caveats, right?
… My only blocker is the rdf:JSON. I'd like a note that say that it may be remove.
pchampin: Yes, that can be done - that is "feature at risk"
<pfps> I would be happier if rdf:JSON was fixed before CR, though
ktk: let's not discuss the blockers here, just try to list them. What else do we have?
AZ: with respect to the Conformance section, there was a discussion on w3c/rdf-concepts#135
<gb> Issue 135 not found
<AndyS> w3c/
<gb> Issue 135 naming RDF 1.2 without triple terms (by pfps) [needs discussion]
<AZ> w3c/
AZ: the decision we voted on is https://
… the profiles were supposed to be named "Basic" and "Full".
… I don't see any mention of RDF 1.2 Basic in the document. Was this decision overriden?
<gkellogg> https://
gkellogg: we have "Classic" conformance defined. It is just a matter of renaming "Classic" to "Basic".
AZ: the discussion was also about naming them "levels of conformance" or "profiles". So this is another difference: the goal was to define an explicit subset of the specification.
gkellogg: the term "profile" has connotations, esp. in HTTP. We should not conflate those two things.
<niklasl> +1 to avoid conflating "profiles" (as WIP concept IMHO); and "conformance levels"
AZ: I agree that we should not confuse the two things. In the discussion before the vote, I was careful to explain that defining "levels of conformance" and defining "profiles" was different.
… and the decision was to define profiles. We can make a new decision, but that's what the current decision is.
ktk: did you notice the editor's note in this section?
AZ: I think that note is even older than the decision.
ktk: is this a blocker for you?
<ktk> q`?
AZ: not necessarily, but I would like clarification.
thomas: the current spec does not contain the unstar mapping, the PR is currently blocked.
… I would like a better explanation of the difference between triple and triple term.
… those are blockers for me.
gkellogg: CR is an important publication milestone, the occasion to get feedback from outside.
… notes and issues marker can give external readers some context about the state of discussions in the group,
… but we should not hold the document.
… Reorganizing the document also should not get in the way of moving to CR.
<thomas> w3c/
<gb> Pull Request 115 add section about 'unstar' mapping (by pchampin) [spec:enhancement]
<AndyS> None of my review comments are blockers.
thomas: I forgot about triple terms in the subject position, but that's also a blocker for me.
… I didn't understand that the stake was this. I think we need more discussion.
pchampin: PR on unstar is blocked by a request to discuss it first
… concepts "works" without RDF-star
pchampin: Graph Isomorphism needs updating for triple terms.
… also whether rdf:dirLangString is necessary or roll into rdf:langString
ktk: Could we just note the work needs doing for Graph Isomorphism
pchampin: I would be happy with an issue marker.
enrico: +1 to graph isomorphism. A number of things need to be fixed in RDF-Semantics, I didn't have the time to review it completely.
… More generally, I think that RDF-Concepts and RDF-Semantics should be written in a non-ambiguous and clean way.
… People are already asking questions about the WG on LinkedIn, showing that things should be clearer.
… Section 1.5 in particular needs improvement.
<niklasl> I have to agree with @enrico , it does not appear ready for CR. But also yes, we can work on it now (ideally within a week)!
<pfps> as far as I can see the isomorphism is acceptable for triple terms, at least at the level of formality of Concepts, and it isn't used in Semantics (at the moment)
<ora> +1 to enrico's call for clarity
enrico: About the unstar mapping, we should look at it more closely before include it in CR.
<pfps> oops, please ignore my previous comment, there are some issues
fsasaki: from the process perspective: CR means the specification is implementation-ready.
… I heard about features such as directional language string, and rdf:JSON.
… I also heard about explanatory text. The latter has less impact on implementations. It can be changed afterwards.
<thomas> triple terms in subject position seem like a feature to me
fsasaki: Everything we do is already public. Going to CR is a signal that things is implementation ready -- and features at-risk need more feedback.
… I encourage us to consider the question "go to CR" from this point of view: not "what do you want to change", but "is this implementation ready"?
AndyS: I agree with fsasaki.
… Another important thing is the deadline for CR. People will usually post comments near the deadline.
… We will also get very general comments -- we have much more observers than participants in the WG.
thomas: I suggest we give it two more weeks, and then move to CR.
<thomas> it seems to me like we should decide about subject position and add unstar before goingto CR
<thomas> .... because those are relevant to implementation
pchampin: note about the process: we don't go to CR directly, we first need horizontal review, which may take 4-6 weeks.
… I think we can make editorial changes during this period.
ktk: I try to summarize the issues I heard:
… - graph isomorphism (fix or put issue marker)
… - section 1.5 and explanation about triple terms
… - triple terms in the subject position
… - do we need the unstar mapping before CR
<niklasl> I assume "explaining triple terms" include "defining propositions"?
ktk: - rdf:JSON at risk
… - "levels of comformance" vs. "profile"
<pfps> I created an issue for isomorphism, which has what I think is the required change.
gkellogg: also the disctinction between "abstract syntax" and "data model"
AndyS: for me this is mostly editorial, we can not change the title of the document
ktk: how do we do that now?
james: I expect to see notes about term identity for triple terms.
<AndyS> https://
james: also, the change of "MUST" to "SHOULD" about supporting ill-type literals should have a note saying that it has not beenadequately considered.
<james> arbitrary -> adequately
fsasaki: we should consider the sublist comprising only the normative items of the list above
thomas: I know that we can discuss for years about triple terms in the subject position, I don't know how to decide.
… But we should discuss it once more.
fsasaki: I suggest we seek agreement on the normative sublist.
<thomas> triple terms in subject position seems like a topic relevant for implementations
gkellogg: I think we should have issues created/updated for everything we need to do.
… we have some archaic issue markers in the document that need to be cleaned up.
… and we should also insert issue markers for other pending issues.
… About rdf:JSON, note that the datatype itself was already defined in JSON-LD. What would be at-risk would be its update by this spec.
pchampin: there are labels for W3C process - labels should be there for each repo
fsasaki: it may be more feasible to do this offline. Picking a victim (not me) to create those issues offline and then iterate.
ktk: pchampin, can you create the issue about graph isomorphism?
gkellogg: actually, there is already an issue
ktk: enrico, niklasl, can you take care of creating/updating an issue about section 1.5
enrico: ok
<niklasl> There is w3c/
<gb> CLOSED Issue 80 where are triple terms allowed (by pfps) [spec:substantive]
ktk: thomas will create/update an issue about triple terms in the subject position.
ktk: what about the unstar mapping?
thomas: we hare a PR for that, IMO good for merging
<gb> Pull Request 115 add section about 'unstar' mapping (by pchampin) [spec:enhancement]
ktk: rdf:JSON, we do already have an issue for that.
<gkellogg> w3c/
<gb> Issue 116 rdf:JSON value space incorrect (by pfps) [ms:CR] [spec:bug]
ktk: levels vs. profile, this is normative, we need to address this. This needs an issue.
ktk: data model vs abstract syntax, do we have an issue for that?
<AZ> About conformance and profiles, here is the issue we can follow: w3c/
gkellogg: no, I can create one.
<gb> Issue 135 naming RDF 1.2 without triple terms (by pfps) [needs discussion]
ktk: term-equality of triple term, james james will create an issue
<fsasaki> https://
ktk: MUST/SHOULD support ill-formed literals. james will create an issue
fsasaki: link above shows the issues marked as "due for CR"
ktk: please everyone, put this label on the issue you create/update
niklasl: there was discussions about the graphic representation
… is this bikeshedding or important for CR?
gkellogg: all the images are accessible (alt description), that's important.
… Updating the image should always match the description.
ktk: thanks you all, adjourned