<AndyS> We must be approaching 5 sigma on this by now.
<thomas> if Ora in room -> scribe Ora
Announcements and newcomers
pchampin: Last week's workshop...
pchampin: It went well, lively discussion, interesting things, papers will be on-line soon.
pchampin: Presentations were recorded.
pchampin: It was a hybrid conference, it was great to see people.
pchampin: There is a lot of interest for RDF-star.
olaf: Announcing that I have been selected to be an Amazon Scholar, I will work with the Amazon Neptune team. Still associate professor in Linköping too.
olaf: RDF-star is one of the topics.
pchampin: Confirmed that process does not limit what a new feature can be. It can be limited by the charter.
ora: proposed a text explaining the distinction btw asserted and quoted
… made a parallel with evaluated/quoted in LISP
AndyS: agreeing with what ora is saying
… going back to the spec: a triple is a 3-tuple, that's all
… there is an infinite set of it, "floating around"
… they are asserted once put into a graph
… in a given graph, a triple maybe both asserted and quoted
pchampin: I do not agree that the chevrons are a quoting operator, they are an embedding operator.
pchampin: In Lisp, you can simply remove the quote. Not so in RDF-star.
pchampin: Context of use makes a triple quoted or asserted.
pchampin: I do not disagree with the analogy, but it could be confusing.
<TallTed> Nitpick: Chevrons are the `«»` glyphs, which are distinct from double angle brackets `<< >>`.
<AndyS> "A quoted triple is a triple used as the subject or object of another triple."
<Zakim> AndyS, you wanted to bring in some current spec text
AndyS: This line from the spec... change it to "...can be used...".
AndyS: Chevrons are doing the quoting.
thomas: Aren't we making things too complicated?
pchampin: I am not making a distinction between quoted and embedded triples.
pchampin: The main role of the chevrons are to "embed" a triple. You can only do this in a certain context.
thomas: Also you can only quote in a certain context.
pchampin: Reluctant to see chevrons as a quoting operator.
<AndyS> Writing a triple as (:s :p :o) then ( (:s :p :o) :q "abc" )
AndyS: Everyone has a different background, everyone's viewpoint is different.
AndyS: Is there anything wrong in the spec?
AndyS: What do we have to do, to change in the spec?
pchampin: Thinking was that something might be missing.
pchampin: I am not against adding Ora's paragraph.
pchampin: Details can confuse...
pchampin: If we think this adds to folks' understanding, then why not.
pchampin: Defer the decision as not everyone has read it.
<Fabio_Vitali> I can't understand where is the text going to end up...
pchampin: Ora please make this into a pull request.
pchampin: Mark as non-normative.
AndyS: I particularly like the last sentence.
Action: ora to turn his proposal in #196 into a PR
pchampin: I did this.
pchampin: Nice side effect was creating some publicity for the Easier RDF repo, https://
pchampin: My feeling is the consensus is "why not, but let's be careful".
pchampin: Next two actions are mine...
pchampin: Not everyone has reviewed the PRs.
pchampin: Still have to push the other one.
PR #204: Classes for RDF-star terminology
pchampin: Fleshing out the vocabulary section.
AndyS: I took existing material, refined a bit.
AndyS: Discuss classes first, before discussing properties.
thomas: What is the source?
pchampin: <scribe missed the answer...>
thomas: Is that another term for graph?
pchampin: No, because of mutability.
thomas: I read it but meaning was not obvious.
pchampin: This is still bare, just trying to define terms not yet defined (RDF-star source).
thomas: It is difficult to discuss terms that are a mathematical abstraction but also very concrete.
thomas: No sense discussing this yet.
<pchampin> PROPOSED: merge #204
<Fabio_Vitali> My list of issues goes up to #203. Where do I find 204?
<gatemezing> AndyS: I guess we don't need to add axioms like disjointness between some clases?
<Fabio_Vitali> anyway +1
Resolution: merge #204
Defining our path
pchampin: From AndyS' email: we should give ourselves some milestones, we are soon one year old, we have achieved a lot.
pchampin: Also the next step: chartering a WG.
pchampin: If all goes well, a future WG will take this up.
AndyS: I predict the WG will revisit a lot of things.
AndyS: Limited value in getting into really fine details.
AndyS: REC-grade doc not needed now.
AndyS: Early on in the WG there will be discussion by new people about what RDF-star really is.
<TallTed> and what RDF-star is NOW, vs original and other earlier papers...
AndyS: We cannot possibly have considered everything.
thomas: Issue #170, referential opacity, is crucial.
thomas: Makes a difference in many use cases, such as provenance.
pchampin: A solution or a discussion?
thomas: A proposal, a solution.
thomas: We should evaluate how much effort this is.
AndyS: Another source of validation exists.
thomas: The proposed semantics does not cover usage.
thomas: Look on the Web.
thomas: I do not have to provide evidence.
thomas: Want a proof of how referential opacity is easy.
thomas: Something that is worked out.
thomas: I need an answer, then I can comment.
pchampin: I did some prototyping in N3. I understand it is not a standard.
thomas: This is not how it would look in RDF.
pchampin: I do not share thomas' feeling on this.
pchampin: Please wait until that section is complete enough.
pchampin: PR not ready yet.
thomas: I am waiting, but I want to check how this works with use cases.
AndyS: We can change how often we have meetings if that helps.
pchampin: Let's use the tag "later" for some.
pchampin: Other than those, we can declare we are done.
Action: pchampin to review issues and propose to tag 'later' all but those necessary to finalize report
<TallTed> confirming -- current meeting schedule is every 2 weeks, so next is Oct 1?
ora: would like to discuss the problem raised in our workshop paper
<Fabio_Vitali> can we have a link to the paper?
ora: the uniqueness of triples in RDF-star makes it impossible to model some common PG patterns
<Fabio_Vitali> @ora thanks
<thomas> good bye