Meeting minutes
ora: We just eard that gkellog passed away a few days ago. Gregg was a very nice guy and a giant in the semantic web community. I don't really know what else to say
ora: [reading Gregg's wife email]
pchampin: The JSON-LD plan to make a special tribute to Gregg in the JSON-LD 1.1 and 1.2 specs
ora: There were at least 9 published specs edited by Gregg
ora: I would like to include in our spec some kind of dedication to Gregg
<TallTed> +100
<niklasl> +100
<pchampin> +1
<lisp> +1
<Dominik_T> +100
<tl> +1
<doerthe> +1
<olaf> +1
<Souri> +1
<pfps> We should carry on
<ktk> post on semantic web list: https://
Approval of last week’s minutes: 1
<ora> PROPOSAL: Accept last week's minutes
<tl> +1
<Dominik_T> +1
<Enrico> +1
<Tpt> +1
<ora> +1
<pchampin> +1
<ktk> +1
<doerthe> +1
<AndyS> +1
<niklasl> +1
<lisp> +1
<fsasaki> +1
<olaf> +1
<TallTed> +1
RESOLUTION: Accept last week's minutes
<rubensworks> +1
<gtw> +1
Identifying issues to solve before CR 2
ora: Let's talk about w3c/
<gb> Issue 169 definition of reifiers is non-normative and seems vague (by rat10) [needs discussion] [propose closing] [ms:CR]
w3c/rdf-semantics#156
<gb> Pull Request 156 Better text in Section 5.3 with the purpose of relating triple terms and asserted triples. (by franconi) [ms:CR] [spec:editorial]
pfps: The change is mostly editorial, the issue is on the last sentence of the change to see if it's suitable or not
<Enrico> https://
Enrico: The point is that we have a formal definition of it. We don't want to say "in other words"
pfps: Strike it for now. If Someone can come up with something that is true we can insert it later
<TallTed> https://
TallTed: new proposal above
<Enrico> https://
<gb> Pull Request 156 Better text in Section 5.3 with the purpose of relating triple terms and asserted triples. (by franconi) [ms:CR] [spec:editorial]
doerthe: What is wrong with the previous formulation
Enrico: It would be wrong because "denotation" talks about triple in the graph but it's not the case
<ora> PROPOSAL: Merge w3c/
<ora> +1
<niklasl> +1
<Dominik_T> +1
<TallTed> +1
<Enrico> +1
<lisp> -> enrico, if the "asserted triples" is not synonymous with " the triples in a graph", how can the former be untrue?
<pchampin> +1
<pfps> +1
<tl> +1
<AndyS> +1
<olaf> +1
<lisp> +0
<gtw> +0
<ktk> +1
<doerthe> +1
<pchampin> lisp: because in the text we are discussing, we are considering an interpretation independently of any graph
<rubensworks> +0
<fsasaki> +1
<Souri> +0
RESOLUTION: Merge w3c/
<gb> Pull Request 156 Better text in Section 5.3 with the purpose of relating triple terms and asserted triples. (by franconi) [ms:CR] [spec:editorial]
<ora> Woohoo!
w3c/rdf-concepts#237
<gb> Pull Request 237 explain the rdf:reifies is deliberately abstract (by pchampin) [needs discussion]
pchampin: This is the counter part of the one we just discussed, in the hope of clarifying everything on reifiers
tl: I have been reading though specs in the last days, I came to the conclusion that semantics is indeed not the place to specify rdf:reifies and the reification process. The schema is a very lean definition of rdf:reifies so it should be in concepts. But it's even more vague than I though, I made a PR to state my understanding.
<gb> Pull Request 144 No connection between propositions and facts in model-theoretic semantics (by rat10) [ms:CR] [spec:enhancement]
<gb> Issue 144 [Editorial] capitalization of "SPARQL string", "SPARQL Query string", and "SPARQL Update string" (by TallTed) [documentation]
tl: I worry that the current state is too vague. I disagree it's a feature, not a bug
tl: I made that rdfs:state proposal, I am fully aware it won't be part of this spec but maybe in the future
tl: In the way it's done now, all the semantic is in the triple term
<Zakim> Enrico, you wanted to comment on closing PR #144 in RDF-Semantics w3c/
<niklasl> +1 for closing that now
Enrico: I think w3c/
pfps: I completely disagree, the wording in concept is adequate, at this point the way ahead is either to vote that everything is fine or have a competing proposal as a PR, then the WG in a very short time could vote to accept it or not
pchampin: tl, our disagreement seems to rely on "reifier denote proposition". There is nothing in either spec that justify that
tl: you are right, it's not there but it should be
<niklasl> It should not be.
pchampin: I disagree, if it should, it should be in SEMANTICS. Denotation is the business of SEMANTICS. You said you agree on what SEMANTICS said
Souri: Just to make sure, we are talking about concepts section 1.5
Souri: For readers, is it possible to put a tiny example when you are defining "triple annotation". It always help. I am not sure if the document is the right place but it would be very helpful
<pchampin> https://
ora: I like that
tl: I came to the conclusion that SEMANTICS is a very abstract document. The semantics define the proposition but CONCEPT defines the triple terms.
tl: I hope you can define the semantic via rdf:reifies
tl: The triple term would be the encoding of the proposition. That's it. Everything else can be defined with rdf:reifies, allowing other properties to define something else
AndyS: The section 1 is informational, it does not define anything. The semantic comes from triples, not individual terms.
<niklasl> +1 to AndyS ; I agree that it does not stop any other use of triple terms.
Enrico: This is an explanation, saying what triple terms are in 1.5
Enrico: This does not say you can't have properties for whatever you want.
<Souri> It will be nice to have a single example in 1.5 (of Concepts spec), for illustration purposes: showing say three reifying triples (two of them sharing the same reifier) and then pointing out the reifying triples, the reifiers, and the triple annotation.
Enrico: I would propose this to close it today
<niklasl> also +1 to Enrico; it explains an expected use.
<niklasl> See w3c/
<gb> Pull Request 62 Align Triple-term reification text with Concepts section (pending CR) (by domel)
lisp: The language introduced in the diff, does not help the reader. The structural relationship says nothing about the interpretation. Any interpretation is left to the application.
tl: With rdfs:state, it would not be a problem, it would be a stronger definition. In case of rdfs:mention, and in no way endorses it, I fear is not possible. Concept says "the triple term encode the proposition, if it is asserted in the graph, it also refers to that".
pchampin: It is generic in the sense that the semantics does not enforce any structure on the property. Every property denote something in the interpretation. The question is that if it's constraint on not by the spec. rdf:reifies is not really constraint outside of its range
pchampin: As pfps suggested, if there is enough support for the PR I put, I propose we merge
pchampin: It seems we agree there should be a paragraph on rdf:reifies. If James can make a PR if you think of a better term than "generic", it would be welcome
Enrico: To answer to James, if we look the text at section 9, there was a notion of type and class. There was a missing part were we talk about rdf:reifies and proposition. What about talking more on rdf:reifies? In RDFS we have more properties related to classes and types, that refers to these concepts
Enrico: We have rdf:reifies that uses the concept of proposition. But it's not used anywhere else, so you can't say more about it.
Enrico: We have a special property rdf:reifies for the users to introduce the reifiers, but it's not formal
Enrico: In semantics we should not say more than we say about class, but then there are the usual patterns
<Zakim> pfps, you wanted to state that I see no reason that "mention" is precluded
Enrico: I think we cannot do much more in section 9 because there is no structural properties. On the other hand, it's interesting to do a good job on RDF concepts
pfps: I am puzzled as why there is anything in our documents that prevents "mention"
ora: To clarify, the thing that worries me is that we venturing again in the temporal progression of the graph, which is completely outside of what we are considering
tl: I am talking about view points, not endorsed statement
lisp: The core of my concern is that the annotation that are applied to the subject of the reifying statement have no necessary bearing on the assertion of the proposition in the graph
<Enrico> to lisp: I blelieve that your concern is addressed in section 1.5 of RDF concepts
lisp: Enrico, post a very short message to the WG about if assertions on the subject of the reifying statement are intended to be assertions on the reifying statement [badly worded, please fix]
<Enrico> my answer: section 1.5
pchampin: tl, about weaker properties than rdf:reifies, a triple does not endorse an other triple. A graph can endorse/entail a given triple. A reifying triple cannot endorse the reified triple
<niklasl> +1 to pchampin
<pfps> ditto
<Enrico> +1 to pchampin