Meeting minutes
approve minutes from last meeting
<pchampin> https://
ktk: minutes approved.
… There were IRC issues, so some stuff is missing.
<pchampin> ora's email: https://
ktk: A couple of things Ora brought up: semantics, and schema definition.
<Doerthe> p+
gkellogg: suggest we get started on repos for FPWDs.
pchampin: I think we could publish some FPWDs for some of the specs.
<Doerthe> No, I wanted to write present+ and did not do that
pchampin: FPWD is not committing to the finished work or even a consensus.
… We can always re-name repos, if the short names change.
… Big issue is naming editors for the specs.
… On a related point, I think we can decide on names. I laid out how I think we should proceed.
Dominik_T: I sent an email about annotations and RDF-star, which we might discuss today.
github repositories and FPWD
gkellogg: we need to create ~20 repositories
… as pchampin pointed out, we can create them and rename them afterwards.
… I have done some work to prepare the initial version of many of these documents,
… but I don't intend to be an editor of most of them.
… For documents that we do not intend to change substansively, we can just make a statement that the document has not changed, and not even change the editors
PROPOSAL: create repos for each of the the different specifications and assign editors later.
+1
<rubensworks> +1
<gtw> +1
+1
<Souri> +1
<AndyS> +1
<Enrico> +1
<Dominik_T> +1
<ktk> +1
<Doerthe> +1
<AZ> +1
<TallTed> +1
<remiceres> +1
RESOLUTION: create repos for each of the the different specifications and assign editors later.
ACTION: pchampin to create the repositories for each spec
<ghurlbot> Created action 10
gkellogg: it is useful to set appropriate permissions for group members.
ktk: are there groups we can use on GitHub?
pchampin: We have two groups (teams). One for the participants, and another for the chairs.
… We can create ad-hoc teams for the editors.
… and we need to make a decision on the level of permissions we grant.
ktk: we can certainly give read permissions for participants.
gkellogg: it is easy to break things unvoluntarily, so write access to the whole group is dangerous.
AndyS: Ora also said something about forming task-groups to keep the work of the main group focused.
AndyS: Can we have agendas a day before the meeting?
… It would help if people knew what was coming up in the meeting, for people who's interest is more focused.
ktk: we discussed that in the chairs meeting.
AndyS: For the task groups, I think it's a good idea to find out how to make progress and then bring back summaries to the WG.
ktk: THat way we can keep important discussions in this group.
AndyS: Task groups aren't decision making.
ktk: Possible topic's from Ora and Enrico.
Enrico: My idea is in line with Peter's discussion and with what Ora discussed.
… We want a correct model-theoretic description of RDF-star.
… I argued that the way of using reified triples to represent model predication does not have a simple counter part in model theory.
RDF-star semantics
Enrico: In RDF-star where we introduce a "meta-triple", it's backwards compatible if it has a direct relationship with traditional RDF reification.
… We could keep backwards compatibility and provide best practices for using that to do modeling.
… Leaving out model predication means that an embedded triple always corresponds to something in the real world.
… So, a statement can have predicates.
… This implies that whenever an event exists, it can become an element of a graph and have its own properties.
… For non-model predication, this is always true.
… The triple can induce the creation of an event.
… Another implication is that reification is universal.
… Whoever has a triple can reify that to talk about it.
… an event doesn't necessarily need to be true (could be imagined).
… This gets down to how bnodes are interpreted within a graph.
… A bnode may or may not identify the same resource. If you have a ground graph, the reification should be the same for everybody.
<Zakim> pchampin, you wanted to ask if '<< :pa a foaf:Person >>' qualifies as an "event"
pchampin: I'm a bit worried about the notion of events; it could be a bit misleading.
… Not all triples represent events.
… Some of the examples used are a bit biased compared with all the triples that might be used.
… We should include triples that are less event-like.
Enrico: Yes, you're right, but those triples aren't really predications.
… The notion of a statement being true is the model aspect.
… If you know the domain of truth, an object or predication is a true statement.
Doerthe: Do we really want to artificially create IRIs? It feels somewhat artificial that we have the notion of a quoted triple and then create an artificial URI.
… Also, I think your use of event-specific modeling might be too narrow.
… whether or not we want to use the event approach depends on where we go.
Enrico: A possibility is to create a new object that maps to a resource.
… I think that RDF-star has the property of defining a triple; a predicate on this is what makes it an event.
… If you want to do more than one statement, then why not use named graphs?
… Or N3, which talks about sets of triples or graphs.
… But here, because there's only one triple, there are notions of predication and reification.
… Perhaps we need to be in semantic agreement with named graphs and N3.
… We're confusing the reification and model predication.
Doerthe: I'm not convinced, but I'd like to hear other opinions.
TallTed: I'm a bit frustrated, as I think Enrico is re-hashing discussion that happened in the CG and has been taken into consideration already.
… This is the third call where reification has been described as the motivation for this group, but there are others.
… We also need to be consistent in our terminology. Let's not talk about encoding "facts", they are assertions.
… Part of what we want to do is to be able to speak about assertions that are made without asserting it ourselves.
… Named graphs are useful things, but they are not fully incorporated into RDF at this point.
… TriG is written with a context which is described as a graph name, but could be interpreted in different ways.
… We can't step on other interpretations.
… Named graphs are important, as they can contradict each other.
… I wish RDF-star could support quoted graphs, but that may not be a group opinion.
… This is more than reification, and isn't about facts or even triples.
Dominik_T: I agree with Ted, but we are talking about annotation of a single RDF triple, not many.
… Talking about N3 is out of scope.
Enrico: I note that the CG document was just syntax. It doesn't get into the semantics.
… If you want a model theory, we need to discuss this.
… There may be a notion of a graph being true, which is not the same as the existence of a resource.
… My role is to remind the group that there is a model theory.
… A number of RDF extensions have not taken this into account.
… For example SPARQL OWL entailment regime.
… RDF is different than other languages.
… The current CG spec is pure syntax. If you want to ground it in model theory, that's an issue.
… Let's start with doing this for one triple, and then we can discuss multiple.
<AndyS> https://
Doerthe: At the beginning we started with model theory before syntax.
<Zakim> pchampin, you wanted to disagree that RDF-star is semantic-less
pchampin: We tried to make a proper model theory for RDF-star but couldn't reach concensus.
… The results might be baroque from a model-theoretic view, but it does have a notion of satisfiability and entailment.
… I'd rather have a standard model-theoretic interpretation, but we do have a semantics.
… It's in the CG report (section 7?)
<pchampin> https://
pchampin: I think Enrico is aware of the section, but we draw different conclusions.
… I say that it is a way of defining the semantics.
Enrico: The fact that I have a resource which is an object in the domain ...
… However, the object represents the truth value of a triple.
<TallTed> a "fact" is ALWAYS true, by definition!
Enrico: There is object in the world which represents the truth value.
<TallTed> a blank node is a node which is identified only by its attributes, without the node itself being specifically identified/named
Enrico: There triples become resources in the domain.
<TallTed> it has nothing to with the "truth" of the asserted attribute values
Enrico: (scribe getting lost, sorry)
… To say it lacks model theoretic semantics is because models are isomorphic to reality.
… If I have objects which do not belong to reality ...
pchampin: I can respond better on the mailing list. We don't agree on what the bnodes represent.
TallTed: A fact is always true, by definition. But, it might be only true in my opinion.
… When i encode it as a triple, its my assertion.
… Blank nodes represent things not directly identified, so it is possible that a blank node is satisfied by one, or more different resources.
<pchampin> "fact" in KR languages (e.g. prolog) means something more like what TallTed calls "assertions", that might explain the discrepencies across speakers
ktk: Ora won't be available next week, as well.
<Souri> exit
<Souri> WHat is the command to quit from irc?