Meeting minutes
ora: We have a new member
… Bilal Ben Mahria
ora: DST switch - there will be one week when Europe and North America are out of sync
… there was a message to the chairs
… it says that the meetings are anchored to the North American time zones
… which means it will be one hour earlier for Europeans during that week
DST switch
Map the annotation syntax to rdfs:states (feedback Semantics TF) 1
ora: We use the issues list as our backlog
… to prioritize our topics
… anyone from the Sem TF who can report on this topic (#128)?
<gb> Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [needs discussion] [discuss-f2f]
<AndyS> Minutes from SemTF -- https://
tl: During the recent Sem TF meeting we went back and forth on the topic
… but there was no agreement
… in the end enrico was convinced that it can be split into two separate topics
… but that is not the solution I was looking for
… I continued working on it
enrico: not clear whether we are discussing the annotation syntax or the purpose of the rdfs:states predicate
… which for me are separate things
… We need to look whether there are different proposals.
… While I was absent for three weeks, I didn't follow the discussions but noticed that they are floating around different topics
<pfps> +1 to making a decision now
pchampin: In contrast to tl I would not like to continue the discussion in the Sem TF
<gkellogg> +1 to pchampin
<AndyS> +1 to pchampin
<tl> w3c/
<gb> Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [needs discussion] [discuss-f2f]
pchampin: because it has been quite long already. I don't think tl has convinced us
<pfps> +1 to pchampin
tl: I posted my latest comment
… I have different possible mappings; they go in different directions.
… I would at least like to get my questions answered.
… I have an open question to niklasl
… Generally, many people here ignore that there is a problem.
… I wouldn't like to have a vote today but, first, answers to my questions.
… The answers that I have been getting so far are very superficial.
pfps: In my opinion, tl has received deep answers. I don't see a reason to go forward in this discussion.
niklasl: I agree with pfps
… I have given well-thought answers.
<niklasl> :Foo :madeOf :Bar {| :rejectedBy :Alice |} {| :believedBy :Bob |} . # Invokes other "intuitions"?
niklasl: I have not seen that others share the intuitions that tl has
<tl> https://
tl: to niklasl, I looked at your example and fixed my examples
… but I had other questions
<Zakim> ora, you wanted to ask how much is this related to the fact that an RDF graph does not have a "memory" of its construction
TallTed: The last comment in that GitHub issue by pchampin tells me that we should design to prevent bad modelling, or provide explicit guidance about what is bad modelling and how to model well.
ora: How much do people here think that the issues brought up by tl are related to whether people consider an RDF graph as a snapshot?
tl: It isn't.
AndyS: When you publish a graph, there is a person behind it. You are making an act in publishing that graph.
… We aren't going to make any progress with another discussion.
… RDF is not multi tenant, meaning that, if you have multiple view, they should be put into separate graphs
niklasl: We going into problem of epistomology
… you have to use domain modelling to capture things
… You can even entail that fact when using OWL, based on domain modelling
tl: About bad modelling, I asked pchampin for an example of how to do it.
<niklasl> It is true if it is asserted
tl: To niklasl, if it is true or not, then we don't need domain modelling for that. Instead, this needs to be part of RDF.
… Yes, we are going in circles.
<Zakim> TallTed, you wanted to touch on "intuitions"
tl: To niklasl, ... (?)
TallTed: Practical questions should be posable very directly
… Regarding intuition, we need to recognize that people who are reading our specs have not participated in our discussions.
… Hence, we should not be relying on any intuitions. Instead, we must make all intuitions explicit.
ktk: To tl, you cannot expect replies. People reply to things if they see value in doing so.
<Zakim> pfps, you wanted to say that many things are just outside the purview of RDF
pfps: I'm hearing we need to do everything in RDF.
… but there are lots of things that RDF doesn't do.
<ora> +1 to pfps
pfps: We are not in the business of solving problems that even philosophers are still discussing.
enrico: I have a proposal - should we as a group continue making a distinction between a different reification property (in addition to rdf:reifies)?
… initially I was slightly in favor of this.
… But based on pfps' argument I am not
… My believe is that RDF is an assembly language.
… More powerful abstractions can be put on top.
<niklasl> +1 to enrico (particularly re. more powerful abstractions on top)
ora: Is your proposal about the distinction between statements about asserted statement versus statements about unasserted statement?
enrico: yes, that's one way of looking at it
TallTed: We need some way say that "this triple is not stated by me but I want to talk about this triple"
… we went further into talking about graphs
… If we had a syntax for quoted graphs, it would be very easy to use that for single-triple graphs.
… The opposite, is very difficult. And we should have learned that now.
… To the discussion about tl, he may not be owed an answer but he is owed respect
… There will be formal objections along the same lines.
<tl> w3c/
<gb> Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [needs discussion] [discuss-f2f]
TallTed: which we will have to address.
tl: I ask everyone to look on the comment I just posted. It's only one page on my screen.
… it shows that we don't know anything.
… It is an unsolved problem.
… It is not only about annotations on unasserted statement but also for asserted statement.
<Zakim> pfps, you wanted to say that clarity is in the eye of the beholder
pfps: tl sees certain things with some form of clarity, I and others see things with another clarity
… That's a problem.
AndyS: We should separate the two issues of syntax.
… I am unclear whether the notion of rdfs:states has been discussed
<tl> Andy please ask again
AndyS: because there is always syntax-related things in the discussion.
<AndyS> w3c/
<gb> Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [needs discussion] [discuss-f2f]
niklasl: I agree that it's important to not consider the syntax for the discussion.
… My problem stems from the fact that we are describing reifiers.
… I never arrive at the same conclusion as tl
<Zakim> Souri, you wanted to say that IMO, for keeping RDF simple and concise, the :s :p :o . triple, if present, should not have anything to do with possible presence or absence of :r1 rdf:reifies <<( :s :p :o )>> OR :r2 rdf:reifies <<( :s :p :o )>> (and what I say about :r1 or :r2).
niklasl: I don't see that there is anything that makes the reifiers asserted. They are just there.
Souri: RDF should be as simple/concise as possible.
… Not to cover things that can be covered by RDFS, OWL, etc
… Two reifiers for the same SPO are completely independent of one another
… as far as RDF is concerned.
… Applications can do something else on top.
Looking at it that way, keeps RDF as the assembly language that it is.
tl: Annotation is complicated. That's the problem.
… The world is not flat.
… It's like giving you a chair with only three legs.
… It is an incomplete design.
… If we drop the syntactic sugar, I would feel less bad about it.
… The annotation syntax is just bogus because it gives an impression of something that is not in the data.
… Or we define it in a way that it is something in the data.
pchampin: I hear TallTed about facing future formal objections, but I think it is an unfair assessment of the situation.
… A lot of effort has been spent on trying to understand and respond to tl's points.
… I will respond to tl's latest comment but I still don't see the issue.
… We have spend a lot of time trying to appreciate tl's points.
enrico: I understand the argumentation of tl and I believe this argumentation is sound.
… But, reification is not only about annotation in the use cases that tl focuses on.
… Since RDF is an assembly language, just triples, this is not the place.
… There are many important things to capture, but RDF is not the place.
<pchampin> I don't claim this is an invalid use case; I just don't agree that it should be baked into the concrete syntax or the data model
enrico: We are introducing a very generic notion of reification.
<pchampin> it can and should be addressed by an additional vocabulary
enrico: tl is not wrong in saying that these use cases should be treated properly, but I don't think we should make that part of RDF
<Zakim> Souri, you wanted to say that IMO the following two rdf:reifies triples can be present at the same time, independent of the presence or absence of the :s :p :o triple in the graph ==> :r1 rdf:reifies <<( :s :p :o )>> ; rdf:type my:Assertion . :r2 rdf:reifies <<( :s :p :o )>> ; rdf:type my:Hypothesis .
Souri: What tl says is important, but it should stay outside of RDF.
<tl> Souri but then we shouldn't support them with syntactic sugar that isn't backed up in the formalism
Souri: It is up to the data designer to create their own vocabulary.
<ora> STRAWPOLL: Do we distinguish between statements about asserted statements and statements about unasserted statements?
ora: I will do a straw poll
<enrico> -1
<gkellogg> -1
<TallTed> +0.9
ora: -1 indicates that you do not distinguish
<tl> n/a
ora: and +1 that you want to distinguish
<ora> -1
<AndyS> -1 : separate syntax and data model
<niklasl> -0.9 (I think this distinction can be modeled for particular types of reifiers using OWL)
<eBremer> -1
<ktk> -1
<pchampin> -1: same as AndyS
<pfps> -1 as far as the question goes
<Souri> -1 to say that we stay with rdf:reifies as the only one (no distinction about asserted vs unasserted)
<olaf> -0.5
<TallTed> Key questions are *where*, *when*, and *how* the distinction is made
<tl> +1 to ted
<Souri> distinction should be outside of RDF, IMO
<pchampin> +1 TallTed
enrico: Sem TF meeting tomorrow about unstar interpretation of triple terms
<TallTed> We have rdf:subject, rdf:predicate, rdf:object which *can* be used for un-asserted, and *could* be populated via semantic sugar (so we never have to *say* those rdf:* predicates)