Meeting minutes
Announcements and newcomers
william: I’m William Van Woensel, currently a research associate in Canada, currently involved with standardizing Notation-3.
… Obviously a bit of overlap with RDF-star. Cited-formulae are a similar construct, and would like to hear about crossover ideas.
… I’ve tried keeping up with the mailing list and hope I can be enlightened.
PR on SPARQL-star built-in functions
<pchampin> https://
pchampin: I also put in a couple of related issues I’d like to close out.
olaf: When the PR is merged the related issues can be closed.
<james> audio is very sporadic
<gatemezing> I have issue to hear olaf
olaf: 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.
<thomas> me too
pchampin: There has been some discussions on the mailing list and in te PR.
pchampin: I understnad james’ questions, but I don’t see how they relate to the PR
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.
… 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.
<AndyS> A previous case - BNODE().
james: This constructed triple term may have a behavior which is different and deserves to be described inline.
pchampin: Your concern is that the blank node constituents of a triple change the semantics.
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.
olaf: I understand the concern, but I don’t think it’s that different from the SPARQL BNODE function.
james: I think readers would appreciate the reference.
AndyS: I don’t understand why you say it creates BNodes, as it contains them but not creates them.
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.
pchampin: It creates a triple as a term.
pchampin: I think it’s an important distinction that it is not asserted, but embedded.
james: I’m trying to understand how blank nodes behave.
gkellogg: I can imagine systems where the bnode identity is key to its relationship with other nodes
… relevant to isomorphism, normalization
… Does adding an embedded triple change the relations of a bnode?
… I think it does.
gkellogg: it’s worth stating, as it could violate some assumptions.
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.
… The function does not affect the data.
<gatemezing> good point AndyS
AndyS: As the subject of the PR, I don’t see a connection.
pchampin: Maybe the clarification james asked for would be welcome.
AndyS: I think it would be a good example that showed different behavior. We don’t know which is right and which is wrong.
gkellogg: it is true that an embedded triple does not put anything in the graph
… but two graphs differing only by the embedded triples they use are not isomorphic
AndyS: but that does not concern this function
… the function does not change the data; and you don't need the function to add embedded triples into the graph
<pchampin> ... If there are different beheviours, let's enumerate them
AndyS: I don’t think Isomorphism is strictly defined in RDF.
pchampin: It is defined.
james: I reiterate my concerns as a reader; this is the place where things of this type are produced.
AndyS: There are other places it’s created.
james: Yes, but this is the place in the document where you actually construct one.
AndyS: I’d think it would be in the definition of RDF-star terms.
… Parsing also produces them. I’m worried that focusing on the TRIPLE function misses the wider context.
pchampin: The creation of the term is not what causes problems. It’s when that created term gets used, either by CONSTRUCT or ...
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.
… I’d rather not to have to delve into the definition of a parser to understand this.
… I thought everyplace that produces an embedded triple produces this type of thing, so this is where you would look.
olaf: Before the call, I was thinking about a discussion section to describe their context.
… I can add some examples along the lines we’ve discussed, including constructing blank nodes within constructed triples.
james: I’d like to see that kind of text.
TallTed: I was going to suggest just that. The differing behavior should be called out with a cross-reference to the places where the effect differs. Point out the different places where it is described.
<gatemezing> Yes, agree
<james> +1
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.
<olaf> +1
<TallTed> +1
<gatemezing> +1
<pchampin> PROPOSAL: leave it to olaf to amend the PR, and merge it afer an announce on the mailing list
<rivettp_> +1
+1
<ora> +1
<pchampin> +1
<AndyS> +1
<gatemezing> +1
<olaf> +1
<TallTed> +1 for the typed which echoed the spoken
<william> +0
<thomas> +1
Resolution: leave it to olaf to amend the PR, and merge it afer an announce on the mailing list
Should <<>> syntax be added to SPARQL-star expressions?
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.
<pchampin> BIND(Triple(?s,?p?o) as ?t)
<pchampin> BIND(<<?s ?p ?o>> as ?t)
pchampin: The idea would be to allow either way of creating an expression, but that requires some additions to the SPARQL-star grammar.
<thomas> that looks natural and intuitive. I woud expect this to be possible
pchampin: The TRIPLE function would still be required for complex expressions. But this might be more natural in some cases.
AndyS: It’s quite doable and doesn’t really change parsing requirements.
… You can’t put expressions inside << >> because of grammar considerations (e.g. “+1”)
… 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.
olaf: I understand it works from the grammar perspective, but whatabout from the evaluation semantics?
… It could be interpreted as syntactic sugar and turn << >> into TRIPLE()
AndyS: That would do for the definition of it s evaluation, but it’s not syntactic sugar.
… 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.
olaf: An alternative would be to extend all the definitions of such expressions to define it explicitly.
AndyS: It makes little difference.
… We don’t have things like COALESCE, which are more difficult.
<pchampin> https://
olaf: Working on this in a separate branch will be a bit tricky due to the other PRs. This will require overlapping changes.
… Similar to the extension of VALUES, which overlaps.
… I’d like to postpone working on this until we’ve merged the PR we talked about before.
… Perhaps we can merge that PR and open a new ticket to satisfy james’ issues.
james: I’m happy that my point has been understood.
AndyS: You could just merge everything into one PR.
olaf: I thought about that, but I think it’s better to keep separate.
… If we can merge the main PR and create a new issue, I can move forward more easily.
<james> +1
<pchampin> PROPOSAL: merge PR 118 now, james will open an issue on the question he asked
+1
<pchampin> +1
<ora> +1
<AndyS> +1
<olaf> +1
<gatemezing> +1
<william> +0
<TallTed> +1
<thomas> 0
Resolution: merge PR 118 now, james will open an issue on the question he asked
Define a URI for the class of embedded triples
pchampin: AndyS suggested we added an IRI to describe the domain or range or properties which are embedded triples.
… 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.
<gatemezing> link to issue https://
pchampin: If we did another temporarily, it would end up becoming permanent.
AndyS: The main thing is the difficulty of changing the URIs down the road.
<AndyS> Literal is in RDFS, Resource is RDFS, Property in RDF. Hmm.
gkellogg: the JSON-LD WG has already augmented the rdf: NS (rdf:JSON, rdf:direction)
… there are some precedents
<ora> Apart from "namespace proliferation", I don't see why it would be terrible to add a new namespace.
<ora> The distinction between RDF and RDFS namespaces has to do with how the work was done, it is not technical.
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.
AndyS: There’s an isDefineBy link; it’s not directly there, but we’re not changing, only adding.
<thomas> I find it rather daring to define that term in the RDF namespace
pchampin: Everything is managed through CVS (or was), so there is some history somewhere.
<gatemezing> Thanks pchampin
pchampin: Technically, I’m now part of the W3C Team :)
… I’ll discuss with Ivan.
<AndyS> As part of RDF-DEV CG, in some sense we have >0 authority but <1.
<pchampin> EmbTriple
pchampin: We need to discuss the term name itself, but that’s bikeshedding.
… We’ll take that to the mailing list.