Meeting minutes
is rdf:dirLangString a required datatype for RDF entailment? 1
ora: pfps abstained from the vote
gkellogg: I don't see how RDF could be consistent without such entailment.
pchampin: I agree; we must have such entailment.
… But, the question is not just do we need semantics, but at which level is the support of semantics required?
… For me, dirLangString is a core part of the model and should be supported in semantics.
AndyS: I don't see how we can not do it; langString is in semantics so that it has one meaning which can't be redefined. We need to do the same for dirLangString.
… They're called out because of the different lexical space.
fsasaki: With regards to CR, developers need to be able to test and report back.
ora: I'm pretty sure we'll hear from implementers if we get this wrong.
AndyS: Peter's asking about semantics, not if it is in the data model.
… Tests will relate to the data model, not the semantics.
pchampin: I think it wasn't so much of a if we put it in semantics, but where.
… What makes sense is in the RDF semantics alongside strings, and langString.
<AZ> you should say "in the RDF entailment regime" rather than "in RDF semantics" because the later is whole semantics document
AndyS: The PR goes through everywhere where langString is mentioned, which is more about data types.
<niklasl> This is the PR w3c/
AndyS: dirLangString is beside langString.
<gb> Pull Request 64 Recognize rdf:dirLangString (by afs) [spec:enhancement]
ora: to the extent that merging a PR means anything, we could do that, but is that a strong enough statement?
james: As I recall, pfps sentiment was that he wanted an explicit statement.
AndyS: Specifically, to put it in the set of recognized data types.
pchampin: D-entailment defines a set where implementations may differ. "D" must be part of the entailment.
… It's not just saying what it means to recognize it, but that it MUST be recognized.
AndyS: The term is that of a "recognized data type". I asked why langString was there in the first place, and didn't get a good answer.
ora: Is saying it is recognized, or do we need to mention D-entailment specifically?
… "recognized" vs "required".
pchampin: Maybe the term is RDF Interpretations.
<pchampin> PROPOSAL: rdf:dirLangString's semantics is defined in RDF-Semantics, and MUST be recognized in RDF interpretations
<gkellogg> +1
<ora> +1
<niklasl> +1
<pchampin> +1
<fsasaki> +1
<eBremer> +1
<Dominik_T> +1
<james> +1
<tl> +1
<gtw> +1
<TallTed> +1
<Tpt> +1
<AndyS> +1
<doerthe> +1
<AZ> +1
<ktk> +1
<Souri> +1
<enrico> +1
RESOLUTION: rdf:dirLangString's semantics is defined in RDF-Semantics, and MUST be recognized in RDF interpretations
Nature / role of triples 2
ktk: We'll time-box this discussion.
enrico: I'm sympathetic with the idea, but wonder what the impact is everywhere?
… We can explain this, but when we say "triple", what do we mean?
… We say triple terms are asserted, but that's sloppy.
… We should not change the notion of "triple".
pchampin: I would say we're not changing the notion of a triple. The only use was to be asserted in a graph.
… That's my mental model; now we need to be clearer when we talk about a triple where it is used.
… When I reviewed RDF Concepts, it didn't seem to need much change.
… The text talks about asserted triples. We need to be clear that a triple in a graph means that the triple is asserted.
… There is a discussion of "appears in the graph", which could be moved to concepts later.
… Most of the text should still work.
enrico: I think some one needs to be responsible for having a pass over the text to put it in order.
tl: We need a name for the triple term we've introduced.
… As far as I say, the spec uses "triple" for the abstract thing, and "statement" for a triple which is asserted.
gkellogg: worries about breaking a concept by over-simplifying it.
pchampin: I agree, a statement is something you make by putting a triple in a graph, it's not the triple itself.
<AndyS> +1 to text outside definitions saying "triple" can be clear by context and that's OK.
pchampin: I don't think we change the terminology, it's more how we introduce the terminology.
… We present them as two different kinds of things; I propose we go back to the CG report and define a triple as something abstract.
… When the context is not enough, we can call it "asserted", when it's used as the object, it's a "triple term".
… Most of text should work as is.
<niklasl> +1 to pchampin
ora: I tend to agree. Are we fixing something that isn't really broken.
enrico: We keep using "triple term" and "triple", and this could fix it.
… The notion of a triple being in a graph is improved by the definition of "appears in a graph".
Souri: Having "asserted triple" and "triple term" makes things clearer.
… It's when a triple is in a graph, or appears as a term.
… If we say triple, it would normally mean "asserted triple". The "asserted" could be added to clarify.
<niklasl> +1 to Souri, this clarifies the two roles that a triple may have (two usages).
ora: You're suggesting we say "asserted triple" only when it's not clear from the context.
tl: I talked about asserted triples in the context of rdf:states. It has become common place in the WG, but I don't know that it is outside.
… Also, what happened to "statement", no one mentions the term any longer.
<pchampin> https://
<pchampin> The statement *corresponds* to the triple, it *is* not the triple.
ora: I think that "triple" has a lot of history; if you're worried that "asserted triple" is not in the spec, we can add it.
enrico: We had a long discussion about the use of "statement". We were convinced from looking at the spec that "statement" is for asserted triple.
… The current spec says that asserted triples are statements.
AndyS: I went through semantics, and the word "statement" comes up 12 times.
<AndyS> https://
AndyS: The first mention is "RDF statements of the form ...", and shows a triple.
niklasl: I agree with Enrico. We will need some work on the text to clarify things.
… Regarding this issue (replacing triple term with triple), I think it makes the specs simpler.
<james> are statements also propositions?
niklasl: I'm not too worried about this. I think this formally makes things simpler.
ora: What are we fixing here? Most of the language is already clear.
pchampin: We need to fix the definnitions of "triple" and "triple terms" in concepts. Currently, they are two different things; they need to be the same thing with different roles.
… That just affects the text where they are defined. I volunteered to make a PR for this.
ora: do we need the resolution?
ktk: I think we need it to limit future discussion.
<gb> Issue 150 Nature / role of triples (by pchampin) [needs discussion]
<gkellogg> +1
<pchampin> PROPOSAL: rephrase the definitions of triple and triple terms in RDF concepts according to w3c/
<fsasaki> +1
<niklasl> +1
<pchampin> +1
<ora> +1
<gkellogg> +1
<tl> +1
<doerthe> +1
<AndyS> +1
<TallTed> +1
<gtw> +1
<eBremer> +1
<Souri> +1
<james> +1
<ktk> +1
<enrico> +1
<AZ> +1
<Tpt> +1
james: As niklasl and enrico suggested, there's the concept of a "proposition". Whatever changes are made should recognize that.
niklasl: I think that's a good idea. Maybe we can coordinate on this.
pchampin: No mention to mention the notion of Proposition in concepts; it's already defined in a PR against semantics.
RESOLUTION: rephrase the definitions of triple and triple terms in RDF concepts according to w3c/
<gb> Issue 150 Nature / role of triples (by pchampin) [needs discussion]
triple terms in subject position - issues with RDF/XML? 3
<niklasl> FYI there is WIP wording in https://
pchampin: Last week, we decided to discuss triple terms in the subject position, but it's not just an RDF/XML issue.
… RDF/XML does point towards the problems of supporting this.
<niklasl> This is the general issue: w3c/
<gb> Issue 138 Triple Terms in Subject Position (by rat10) [ms:CR] [spec:substantive]
pchampin: Another argument against triple terms in the subject position is that we are encouraging people to only use triple terms as the object of rdf:reifies. Saying otherwise is sending mixed signals.
tl: I was in favor of this, but I re-thought about it, as it's been in the abstract grammar.
… If I want to talk about the type, why can't I create a reifier for that? It seems like a hack.
… In RDF, we talk about something being asserted.
… If we treat triple terms differently, we look at only a single use case.
… There are things that have meaning, and it would be bad to dis-allow this.
… It would say that the whole construct is just about a single use case. Not saying something about it.
… I think we're re-making the "seminal mistake".
… If it doesn't work in some syntax, I don't think that's a problem.
niklasl: I disagree; primarily because I disagree with the use case, as the statement is about an abstract meaning, which requires a reifier.
<pchampin> For future reference, the seminal mistake: https://
niklasl: Even in your explanation, you use a reifier.
… In RDF, we use names to describe things and we have a literal structural term which is abstract, denoting the value in the value space.
… Similarly, triple terms are structural, and are used to refer to the meaning of the triple, which is very abstract.
… I was more convinced that we should not allow this in concrete syntaxes because it is unsafe.
… Similar reasoning to why literals can't be subjects.
… I'm unconvinced by tl's argument. At the logical level, I see things differently.
Souri: I fully support those two points: only in the object position, and only with rdf:reifies.
… But, from a practical point of view, users do a lot of things. The minimum we give them would be preferable rather than introduce too much false choice.
… As an implementor, the implementation gets harder when we allow too much flexibility.
… I think this is good rationale to restrict to the object position.
<ora> STRAWPOLL: Disallow triple terms in the subject position
ora: I want to see if people are in favor of the restriction.
<ora> +1
<gkellogg> +1
<enrico> +0
<doerthe> -1
<tl> -1
<niklasl> +1
<AZ> -1
<pchampin> +0.5
<ktk> +1
<james> -1
<gtw> +1
<Souri> +1 for restriction
<Tpt> +0.5
<fsasaki> +1
<AndyS> +0.5
<TallTed> +0.7
<eBremer> +0
<james> does the restriction apply to reifier?
ora: we need to hear from people that don't support the position.
doerthe: For me, having it only in the object position seems totally random.
… I could live with it, as we allow it in the semantics, but I don't see the added value of the restriction.
ora: Would you be more in favor if it included a restriction on rdf:reifies?
doerthe: Not really.
james: My view of RDF is governed by a notion of symmetry; to restrict it is unnecessary, which will lead to problems.
… Similar to the restriction on rdf:reifies.
… Asymmetry in a statement is a bad idea.
fsasaki: I understood that doerthe could live with it. Maybe we can get an understanding of what people mean by "-1".
<Zakim> TallTed, you wanted to note that RDF has always been asymmetric -- literals have never been allowed in subject position except in Generalized RDF (and SPARQL)
TallTed: I don't understand how you can believe that RDF is symmetric, as it's never been so (literals).
james: This is a new term, which is in many ways similar to things which are nodes.
… If the group argued for treating it as a literal, it may make more sense.
<fsasaki> To add to my question: one could re-phrase in a binary way "could live with it" vs. "could not live it". But maybe not today since there is not enough time to think on it
TallTed: Your model is that it is symetric.
james: It's symmetric for nodes.
niklasl: In my mental model, literals are also nodes in the graph. IRIs and BNodes are nominal. I don't know what they denote until I learn more through triples.
… With literals and triple terms, as fixed point structural resources, they are wholly defined by their constituents.
<doerthe> what do they mean?
ora: We're out of time, and can't conclude the discussion.
ktk: It would be interesting to know what would be a common ground.
ora: If you voted -1, please send something to the mailing list so we can find common ground.