15:37:53 <RRSAgent> RRSAgent has joined #rdf-star
15:37:53 <RRSAgent> logging to https://www.w3.org/2021/03/05-rdf-star-irc
15:37:55 <Zakim> RRSAgent, make logs Public
15:37:56 <Zakim> please title this meeting ("meeting: ..."), pchampin_
15:38:04 <pchampin_> agenda: https://lists.w3.org/Archives/Public/public-rdf-star/2021Mar/0019.html
15:38:04 <agendabot> clear agenda
15:38:04 <agendabot> agenda+ Announcements and newcomers
15:38:04 <agendabot> agenda+ Open actions
15:38:04 <agendabot> agenda+ PR on SPARQL-star built-in functions
15:38:04 <agendabot> agenda+ Should <<>> syntax be added to SPARQL-star expressions?
15:38:07 <agendabot> agenda+ Define a URI for the class of embedded triples
15:38:09 <agendabot> agenda+ Open-ended discussions
15:38:31 <pchampin_> agenda?
15:47:16 <pchampin> this is a test
15:53:49 <pchampin> Meeting: RDF-star
15:53:53 <pchampin> chair: pchampin
15:54:02 <pchampin> date: 05 March 2021
15:57:26 <gkellogg> gkellogg has joined #rdf-star
15:58:06 <pchampin> Previous meeting: https://w3c.github.io/rdf-star/Minutes/2021-02-26.html
15:58:12 <pchampin> Next meeting: https://w3c.github.io/rdf-star/Minutes/2021-03-12.html
15:58:21 <TallTed> TallTed has joined #rdf-star
16:00:24 <james> james has joined #rdf-star
16:01:25 <thomas> thomas has joined #rdf-star
16:01:35 <olaf> olaf has joined #rdf-star
16:01:53 <gatemezing> gatemezing has joined #rdf-star
16:02:05 <gatemezing> present+
16:02:10 <TallTed> present+
16:02:24 <gkellogg> present+
16:02:30 <thomas> present+
16:02:42 <pchampin> present+
16:03:10 <ora> ora has joined #rdf-star
16:03:44 <rivettp> rivettp has joined #rdf-star
16:04:00 <olaf> present+
16:04:07 <ora> present+
16:04:08 <AndyS> AndyS has joined #rdf-star
16:04:11 <rivettp> present+
16:04:14 <AndyS> present+
16:04:19 <gatemezing> Zakim, who is here?
16:04:19 <Zakim> Present: gatemezing, TallTed, gkellogg, thomas, pchampin, olaf, ora, rivettp, AndyS
16:04:21 <Zakim> On IRC I see AndyS, rivettp, ora, gatemezing, olaf, thomas, james, TallTed, gkellogg, RRSAgent, agendabot, Zakim, pchampin, rhiaro
16:04:53 <gkellogg> scribe: gkellogg
16:05:04 <james> present+
16:05:13 <ora> I can hear
16:06:04 <william_van_woensel> william_van_woensel has joined #rdf-star
16:06:33 <william> william has joined #rdf-star
16:07:08 <gatemezing> scribe: gatemezing
16:07:09 <pchampin> topic: Announcements and newcomers
16:07:38 <pchampin> scribe: gkellogg
16:08:06 <pchampin> q?
16:08:19 <rivettp_> rivettp_ has joined #rdf-star
16:08:57 <gkellogg> william: I’m William Van Woensel, currently a research associate in Canada, currently involved with standardizing Notation-3.
16:09:38 <gkellogg> … Obviously a bit of overlap with RDF-star. Cited-formulae are a similar construct, and would like to hear about crossover ideas.
16:09:54 <gkellogg> … I’ve tried keeping up with the mailing list and hope I can be enlightened.
16:10:07 <pchampin> q?
16:10:31 <pchampin> topic: PR on SPARQL-star built-in functions
16:10:44 <pchampin> https://github.com/w3c/rdf-star/pull/118
16:10:57 <gkellogg> pchampin: I also put in a couple of related issues I’d like to close out.
16:11:33 <gkellogg> olaf: When the PR is merged the related issues can be closed.
16:11:38 <james> audio is very sporadic
16:11:39 <gatemezing> I have issue to hear olaf
16:12:02 <gkellogg> … The PR brings in the 5 built-in functions for constructing and accessing triple components and to see if a term is a triple or not.
16:12:05 <thomas> me too
16:12:57 <pchampin> q?
16:13:00 <gkellogg> pchampin: There has been some discssions on the mailining list and in te PR.
16:13:17 <james> q+
16:13:23 <pchampin> ack james
16:14:24 <gkellogg> pchampin: I understnad james’ questions, but I don’t see how they relate to the PR
16:15:12 <gkellogg> james: This is the first time there’s an explicit operator to construct such a term. It’s the first term in RDF, which in other parts of RDF has a behavior relating to the graph within which the statement is made.
16:15:42 <gkellogg> … It’s the first itme it can include a blank node which has such behavior. It depends on the relationship between the label and the designated node which is problemative.
16:15:48 <gatemezing> s/discssions on the mailining/discussions on the mailing
16:16:00 <AndyS> A previous case - BNODE().
16:16:05 <olaf> q+
16:16:07 <gkellogg> … This constructed triple term may have a behavior which is different and deserves to be described inline.
16:16:37 <gkellogg> pchampin: Your concern is that the blank node constituents of a triple change the semantics.
16:17:15 <AndyS> q+
16:17:20 <gkellogg> james: I sent an answer about them being opaque terms. The document should be supportive of users and not require they understand all the implications.
16:17:28 <pchampin> ack olaf
16:18:00 <gkellogg> olaf: I understand the concern, but I don’t think it’s that different from the SPARQL BNODE function.
16:18:22 <gkellogg> james: I think readers would appriciate the reference.
16:18:22 <pchampin> ack AndyS
16:18:50 <gkellogg> AndyS: I don’t understand why you say it creates BNodes, as it contains them but not creates them.
16:18:52 <gatemezing> s/appriciate/appreciate
16:19:34 <pchampin> q+
16:19:37 <gkellogg> james: I’m not saying it creates BNodes, but it’s the first time you can construct a statement containing bnodes. The behavior differs (slightly) from the way that statements are known in RDF.
16:19:49 <pchampin> ack pchampin
16:20:21 <gkellogg> pchampin: It creates a triple as a term.
16:20:23 <gkellogg> q+
16:21:10 <gkellogg> pchampin: I think it’s an important distinction that it is not asserted, but embedded.
16:21:21 <AndyS> q+
16:21:28 <pchampin> ack gkellogg
16:21:34 <gkellogg> james: I’m trying to understand how blank nodes behave.
16:21:41 <pchampin> scribe: pchampin
16:22:09 <pchampin> gkellogg: I can imagine systems where the bnode identity is key to its relationship with other nodes
16:22:18 <pchampin> ... relevant to isomorphism, normalization
16:23:01 <pchampin> ... Does adding an embedded triple change the relations of a bnode?
16:23:05 <pchampin> ... I think it does.
16:23:43 <gkellogg> scribe: gkellogg
16:24:25 <pchampin> q?
16:24:28 <pchampin> ack AndyS
16:24:34 <gkellogg> gkellogg: it’s worth stating, as it could violate some assumptions.
16:25:09 <gkellogg> AndyS: When the tirple function creates an embedded triple, it’s not putting it in the graph. It would be not different than if you put annotation syntax into a CONSTRUCT.
16:25:19 <gkellogg> … The function doesn ot affect the data.
16:25:19 <gatemezing> good point AndyS
16:25:22 <gkellogg> q+
16:25:46 <gkellogg> … As the subject of the PR, I don’t see a connection.
16:26:00 <gkellogg> pchampin: Maybe the clarification james asked for would be welcome.
16:26:00 <gatemezing> s/doesn ot/does not
16:26:23 <pchampin> ack gkellogg
16:26:26 <gkellogg> AndyS: I think it would be a good example that showed different behavior. We don’t know which is right and which is wrong.
16:26:33 <pchampin> scribe: pchampin
16:26:51 <pchampin> gkellogg: it is true that an embedded triple does not put anything in the graph
16:27:09 <pchampin> ... but two graphs differing only by the embedding triples they use are not isomorphic
16:27:29 <pchampin> AndyS: but that does not concern this function
16:27:49 <pchampin> ... the function does not change the data; and you don't need the function to add embedded triples into the graph
16:28:05 <gkellogg> scribe: gkellogg
16:28:07 <pchampin> ... If there are different beheviours, let's enumerate them
16:28:15 <james> q+
16:28:39 <gkellogg> AndyS: I don’t think Isomorphism is strictly defined in RDF.
16:28:59 <pchampin> ack james
16:29:01 <gkellogg> pchampin: It is defined.
16:29:20 <gkellogg> james: I reiterate my concerns as a reader; this is the place where things of this type are produced.
16:29:29 <gkellogg> AndyS: There are other places it’s created.
16:29:44 <gkellogg> james: Yes, but this is the place in the document where you actually construct one.
16:29:54 <gkellogg> AndyS: I’d think it would be in the definition of RDF-star terms.
16:30:29 <gkellogg> … Parsing also produces them. I’m worried that focusing on the TRIPLE function misses the wider context.
16:30:30 <TallTed> s/the embedding triples they use/the embedded triples they use/
16:30:57 <gkellogg> pchampin: The creation of the term is not what causes problems. It’s when that created term gets used, either by CONSTRUCT or ...
16:31:42 <gkellogg> james: That is true, but you can describe in each location, or have a summary in the place where you create one. If I want to understand what a parser does, I need to look somewhere.
16:32:20 <gkellogg> … I’d rather not to have to delve into the definition of a parser to understand this.
16:32:55 <olaf> q+
16:32:55 <gkellogg> … I thought everyplace that produces an embedded triple produces this type of thing, so this is where you would look.
16:32:56 <TallTed> q+
16:33:07 <pchampin> ack olaf
16:33:50 <gkellogg> olaf: Before the call, I was thinking about a discussion section to describe their context.
16:34:20 <gkellogg> … I can add some examples along the lines we’ve discussed, including constructing blank nodes within constructed triples.
16:34:33 <gkellogg> james: I’d like to see that kind of text.
16:34:49 <pchampin> ack TallTed
16:35:44 <gkellogg> TallTed: I was going to suggest just that. The differing behavior should be called out with a cross-record. Point out the different places where it is described.
16:36:48 <TallTed> s/cross-record/cross-reference to the places where the effect differs/
16:36:57 <gatemezing> Yes, agree
16:36:59 <james> +1
16:37:01 <gkellogg> pchampin: I think olaf has enough information to amend the PR. Once the modifications are done olaf can inform and we’ll give it a few days before merging.
16:37:02 <olaf> +1
16:37:07 <TallTed> +1
16:37:12 <gatemezing> +1
16:37:14 <pchampin> PROPOSAL: leave it to olaf to amend the PR, and merge it afer an announce on the mailing list
16:37:15 <rivettp_> +1
16:37:17 <gkellogg> +1
16:37:21 <ora> +1
16:37:25 <pchampin> +1
16:37:28 <AndyS> +1
16:37:30 <gatemezing> +1
16:37:38 <olaf> +1
16:37:43 <TallTed> +1 for the typed which echoed the spoken
16:38:08 <william> +0
16:38:08 <thomas> +1
16:38:29 <pchampin> RESOLVED: leave it to olaf to amend the PR, and merge it afer an announce on the mailing list
16:38:46 <pchampin> topic: Should <<>> syntax be added to SPARQL-star expressions?
16:39:23 <gkellogg> pchampin: We now have a way to build a triple as a term using the TRIPLE function. There was discussion about also using the << >> syntax.
16:39:30 <pchampin> BIND(Triple(?s,?p?o) as ?t)
16:39:41 <pchampin> BIND(<<?s ?p ?o>> as ?t)
16:40:03 <gkellogg> … The idea would be to allow either way of creating an expression, but that requires some additions to the SPARQL-star grammar.
16:40:31 <thomas> that looks natural and intuitive. I woud expect this to be possible
16:40:42 <gkellogg> … The TRIPLE function would still be required for complex expressions. But this might be more natural in some cases.
16:40:43 <pchampin> q?
16:41:10 <gkellogg> AndyS: It’s quite doable and doesn’t really change parsing requirements.
16:41:42 <gkellogg> … You can’t put expressions inside << >> because of grammar considerations (e.g. “+1”)
16:42:30 <gkellogg> … I’d rather have them added as a Primary Expression, so that it can be used anywhere such an expression can be used. It could create some odd legal usages, but better than a lot of special cases.
16:42:41 <pchampin> q?
16:42:57 <olaf> q+
16:43:02 <pchampin> ack olaf
16:43:26 <gkellogg> olaf: I understand it works from the grammar perspective, but whatabout from the evaluation semantics?
16:43:47 <gkellogg> … It could be interpreted as syntactic sugar and turn << >> into TRIPLE()
16:44:04 <gkellogg> AndyS: That would do for the definition of it s evaluation, but it’s not syntactic sugar.
16:44:37 <gkellogg> … Users typicalliy want to be sure that what they type in will come out again, and if you do a simple substitution it won’t. But the definition of evaluation would be the same.
16:44:56 <gkellogg> olaf: An alternative would be to extend all the definitions of such expressions to define it explicitly.
16:45:23 <gkellogg> AndyS: It makes little difference.
16:45:35 <pchampin> q?
16:45:53 <gkellogg> … We don’t have things like COALESCE, which are more difficult.
16:46:11 <pchampin> https://github.com/w3c/rdf-star/issues/117
16:46:35 <olaf> q+
16:46:38 <pchampin> ack olaf
16:47:20 <gkellogg> olaf: Working on this in a separate branch will be a bit tricky due to the other PRs. This will require overlapping changes.
16:47:53 <gkellogg> … Similar to the extension of VALUES, which overlaps.
16:48:24 <gkellogg> … I’d like to postpone working on this until we’ve merged the PR we talked about before.
16:48:45 <gkellogg> … Perhaps we can merge that PR and open a new ticket to satisfy james’ issues.
16:48:58 <gkellogg> james: I’m happy that my point has been understood.
16:49:27 <gkellogg> AndyS: You could just merge everything into one PR.
16:49:40 <gkellogg> olaf: I thought about that, but I think it’s better to keep separate.
16:50:14 <gkellogg> … If we can merge the main PR and create a new issue, I can move forward more easily.
16:50:40 <james> +1
16:51:02 <pchampin> PROPOSAL: merge PR 118 now, james will open an issue on the question he asked
16:51:05 <gkellogg> +1
16:51:06 <pchampin> +1
16:51:14 <ora> +1
16:51:16 <AndyS> +1
16:51:16 <olaf> +1
16:51:16 <gatemezing> +1
16:51:17 <william> +0
16:51:19 <TallTed> +1
16:51:30 <thomas> 0
16:52:04 <pchampin> RESOLVED:  merge PR 118 now, james will open an issue on the question he asked
16:52:19 <pchampin> q?
16:52:29 <pchampin> topic: Define a URI for the class of embedded triples
16:53:03 <gkellogg> pchampin: AndyS suggested we added an IRI to describe the domain or range or properties which are embedded triples.
16:54:08 <gkellogg> … There’s been some discussion,, particularly regarding the namespace. AndyS suggested we define it in the RDF space (RDFS?). We can’t change the document, but a future WG could and we don’t want to add to namespace proliferation.
16:54:26 <gatemezing> link to issue https://github.com/w3c/rdf-star/issues/102
16:54:35 <gkellogg> … If we did another temporarily, it would end up becoming permanent.
16:55:01 <gkellogg> AndyS: The main thing is the difficulty of changing the URIs down the road.
16:55:04 <gkellogg> q+
16:55:15 <pchampin> ack gkellogg
16:55:19 <pchampin> scribe: pchampin
16:55:24 <AndyS> Literal is in RDFS, Resource is RDFS, Property in RDF. Hmm.
16:55:39 <pchampin> gkellogg: the JSON-LD WG has already augmented the rdf: NS (rdf:JSON, rdf:direction)
16:55:48 <pchampin> ... there are some precedents
16:55:50 <ora> Apart from "namespace proliferation", I don't see why it would be terrible to add a new namespace.
16:56:03 <pchampin> scribe: gkellogg
16:56:12 <gatemezing> q+
16:56:15 <ora> The distinction between RDF and RDFS namespaces has to do with how the work was done, it is not technical.
16:56:18 <pchampin> ack gatemezing
16:57:18 <gkellogg> gatemezing: I wanted to understand the updates in an earlier namespace. The update was in 2019, so my concern is that there’s no metadata regarding the changes and the Turtle file doesn’t describe changes.
16:57:36 <gkellogg> AndyS: There’s an isDefineBy llink; it’s not directly there, but we’re not changing, only adding.
16:58:04 <thomas> I find it rather daring to define that term in the RDF namespace
16:58:09 <gkellogg> pchampin: Everything is managed through CVS (or was), so there is some history somewhere.
16:58:22 <pchampin> q?
16:58:23 <gatemezing> Thanks pchampin
16:59:23 <gkellogg> pchampin: Technically, I’m now part of the W3C Team :)
16:59:26 <gatemezing> s/llink/link
16:59:32 <gkellogg> … I’ll discuss with Ivan.
16:59:37 <AndyS> As part of RDF-DEV CG, in some sense we have >0 authority but <1.
17:00:21 <pchampin> EmbTriple
17:00:34 <gkellogg> pchampin: We need to discuss the term name itself, but that’s bikeshedding.
17:00:55 <gkellogg> … We’ll take that the the mailing list.
17:01:13 <pchampin> q?
17:01:22 <gatemezing> s/the the/to the
17:02:01 <olaf> olaf has left #rdf-star
19:03:20 <pchampin> pchampin has joined #rdf-star