Meeting minutes
<TallTed> *sighs* overlaid FedID CG, RDF-Star WG, DID WG, Privacy CG, and Web Payments WG
<ora> We need to figure out how the dynamic between on-site and remote is going to work...
<ora> Hard to tell who is talking in the meeting room. I suggest the meeting be "driven" and chaired from there.
<ora> Yes, queue.
<TallTed> usually best if scribes can be in the big room
introductions
<Arnaud> +present Arnaud Le Hors (IBM)
ktk: sorry for the misunderstanding about my email
… I didn't mean to start the meeting at 10:30, only the discussion with i18n
ora: Ora Lassila, AWS, co-chair of this group. I have been a very active participant of W3C, co-editor of the first RDF spec.
ktk: Adrian Gschwendt, CEA of Zazuko. I didn't feel comfortable at first to be co-chair.
pchampin: Pierre-Antoine Champin, W3C fellow from Inria. Team contact.
AndyS: Andy Seaborne, Apache foundation. Have been implementing RDF stuff, then focused on SPARQL.
enrico: Enrico Franconi, researcher in knowledge representation. Worked in past W3C groups. Interested in the semantics of RDF-star
Tpt: Thomas Pellissier-Tanon. I have an implementation of SPARQL(-star) in Rust.
niklasl: Niklas, national library of Sweded. Interested in RDF and JSON-LD.
Dominik_T: Interested in RDF and Property Graph. RDF-star is important in this landscape.
richard-lea: started working on RDF 5 years ago in my PhD.
AZ: associate prof in St-Etienne, France. Interested in the semantics part of RDF-star.
pfps: Invited expert in the group, interested in the semantics of RDF as well as SPARQL
TallTed: with Openlink Software, provider of Virtuoso, engine powering public SPARQL endpoints for DBpedia, Uniprot, many others in https://
doerthe_: TU Dresden, computantional logics group. Initially interested in N3, but I see some similarity with this group.
Arnaud: AC-rep of IBM, was involved for a long time in RDF-related groups. Not involved in this group, but interested in catching up.
fabien_gandon_: Inria, my group has been implementing RDF since the last century: Corese (implementing SPARQL, SHACL...). We intend to do so for RDF-star.
timbl: I developed the N3 language to make it easy to scribble RDF and talk about it on IRC.
… Then we put in curly brackets to be able to talk about graphs. There was no model theory for it.
… The curly brackets in N3 made it possible to express rule, or express metadata about graphs.
… RDF-star worries me: is it useful to restrict ourselves to talk about only one triple.
… Making triples a first-class object is counter productive.
jyrossi: Canton Consulting, joined W3C in 2014. Currently diving into Semantic Web tech, and doing a PhD for representing legal rules.
andrei: Andrei Ciortea, univ St Gallen, co-chair of the web agents CG
rem: Rem Collier, I work on multi-agents systems. Co-chair of the web agents CG
segura: ...
ora: I'm happy to see so many people. Sad not to be here in person (I was supposed to be).
… Happy to see people from my past lives.
… Agents were the reason why I got into the semantic web, so happy to see Rem and Andrei here.
Agenda of the day
ora: we have a list of big topic (i18n, use-cases, semantics, SPARQL)
… then smaller things as issues on github
… https://
… and of course, any other business
ktk: challenge of syncing up between on-site and on-line
… if people on-site discuss things with each other, please bring them up in the call
ora: what's the best way to contact people directly?
ktk: ping on IRC?
ktk: maybe make a short summary of where we are?
ora: the WG has taken up the work of the CG
… https://
… he have a few big things, and the bunch of small things
… the small things are not strictly related to the RDF-star CG. We have a few things to fix in RDF 1.1 and SPARQL 1.1 .
… One of the big thing is to find a semantics for reification.
… In the original WG, I pointed out that reification was introducing some form of modal logic,
… and as soon as I said that, nobody wanted to touch it.
… To me it is a big discussion, we need to discuss about the semantics of named graphs, statements, groups of statements.
… We have worked on use-cases; the hope is that in the end, RDF 1.2 reflects the things brouht in these use-cases.
ktk: we need to touch pretty much all RDF specs in existence: a lot of work.
… gkellogg and AndyS did a tremendous work in bringing old specs up to date with the current formats.
pchampin: we have 18 rec-track documents, plus a few more notes
ktk: a few people outside the group were confused about the existing SPARQL 1.2 WG, which has been renamed to SPARQL-dev.
… Everyone projects different things onto this group. pfps is keeping us on track .
… Not sure what we will end up to. RDF 1.2 may become a living standard.
… Sometimes we get lost in details, hopefully we can take some big issues of the plate today.
timbl: could you add N3 to that long list of documents?
ktk: I would like to say yes but I probably shouldn't!
<TallTed> ((( ...speaker queue is rather vital for this form of meeting... )))
doerthe_: I would like to do that too, but I don't think we can sneak it in.
<pfps> isn't having RDF 1.2 match N3 putting the cart before the horse? surely an interest group should follow the lead of a working group, not vice-versa
ora: I am not opposed to discussing N3. The best way forward is to bring some use-cases making a point for including N3.
timbl: [question about bnodes in RDF-star]
<niklasl> Are we talking about I18N in 10 minutes (10:30)?
<Zakim> AndyS, you wanted to ask for a time for SPARQL so a guest can join
ora: do not think in terms of design, think in terms of requirements
AndyS: can we set a specific timeslot for the SPARQL discussion, so that our guest can know when to join?
… Directly after lunch (14:30) would make sense.
ktk: works for me.
<Zakim> TallTed, you wanted to suggest working *with* N3 WG, rather than picking up N3 ourselves
<Arnaud> re: N3 - can the WG pick up new deliverables without a charter update? I'm afraid not...
TallTed: It would be far more productive to work *with* the N3 CG than trying to pick it up ourselves.
… Use-cases are important: describe what you need to do and can not do with what we have or have been working on here, thus far.
<pfps> I agree with Arnaud
<Zakim> fabien_gandon_, you wanted to ask the opinions about the set of syntaxes
fabien_gandon_: it would be great to have a vision of the syntaxes. We have Turtle/Turtle-star, JSON-LD, YAML-LD, RDFa... RDF/XML is stuck with RDF 1.0.
… Do we want to keep multiplying the syntaxes? Can we afford it?
ktk: do you want to add that to the agenda?
fabien_gandon_: I'm happy to take it offline, but I would like other people's vision on that.
<Zakim> niklasl, you wanted to mention the contrast between reification and named graphs (based on our use cases)
<TallTed> For those unfamiliar, our list of repositories gives an idea of what we're already working on -- https://
timbl: RDF/XML should be deprecated
fabien_gandon_: I would formally object to that, we have important use-cases for RDF/XML
niklasl: I brought up some use-cases.
<fabien_gandon_> timbl: in that case RDF/XLM should have named graph support
<niklasl> w3c/
niklasl: Importance of differentiating the use-cases for quoted triples and the use-cases for named graphs.
… We need use-cases and examples to see if that makes sense.
ktk: I guess we will discuss this in the use-cases session.
(without opinion!) RDF/XML continues to be significantly used in certain domains. e.g. Bio/pharma, (Uniprot). Financial reporting.
<timbl> Sure, Fabien, if you have use caes with loys of rdf/xml then let's not deprecate it But lets add literal subgraphs to it. We did that in the code.
ora: gkellogg has join, please introduce yourself
gkellogg: I have been working on most of the rdf-X documents
<Arnaud> I remember the time when we were fighting the confusiong between RDF/XML and RDF, we went on and put on the REC track a bunch of the existing formats: Turtle RDFa etc and thought this should made it clear that RDF/XML was merely a serialization format and not RDF. It sounds like now the number of serialization formats is causing some confusion too...
<ora> I will go and make coffee...
<TallTed> better link to our repositories/documents -- w3c/
pchampin: 4 slots : 9:30-11:00, 11:30-13:00, 14:30-16:30, 17:00-18:30
<TallTed> Arnaud -- At that past time, there was a perception that RDF/XML was the primary, if not the only, "native" serialization of RDF. I don't think the same confusion is happening now, though there is sometimes a question of which serialization is best for (or even capable of) a given task.
The "little things" list https://
<TallTed> Wiki page or spreadsheet or somesuch for the scheduling?
<fabien_gandon_> We had a proposal (W3C Member Submission) for the source/graph syntax extension https://
<ktk> Break 11:00 - 11:30
<ktk> * I18N
<ktk> * Use Cases 11:30 - 12:00
<ktk> * "Little things"
<ktk> Lunch 13:00 - 14:30
<ktk> * SPARQL 14:30 - 16:00
<ktk> Break 16:30 - 17:00
<ktk> * Semantics
<ktk> End: 18:30
<ktk> sorry i14n would be now
<fabien_gandon_> Tim, I agree, that's why we had a proposal (W3C Member Submission) for the source/graph syntax extension https://
Joint session with i18n
gkellogg: [presenting slides] we have 3 issues to discuss
… 1) nomencrature for strings in RDF w3c/rdf-concepts#59
<gb> Pull Request 59 Improve Unicode terminology and term references. (by gkellogg) [i18n-tracker] [needs discussion] [spec:substantive]
gkellogg: It was unclear exactly what "unicode string" meant in the context of RDF specs
… the PR is defining "RDF string" as a sequence of Unicode coide points restricted to be Unicode scalar values
… (all code points except surrogate pairs)
addison: I made some comments, it is shaped up very nicely
… you also took from old conversations.
… I think you are in the right place.
… We have guidelines for HTML, but less so for groups like yours. We need to improve this.
gkellogg: there was a discussion about the use of code points or code units
addison: code units would mean that you have a specific encoding (e.g. UTF-8)
… but as you are dealing with strings as a seq of logical characters, which is the right thing to do.
<TallTed> "logical Unicode characters"?
addison: "unicode scalar values" would be even more accurate than "unicode code point", but I would not go to "code unit"
<Zakim> pfps, you wanted to mention that some RDF implemenations current permit surrogate code points in lexical values
pfps: I would prefer to go for "unicode scalar value"
… some RDF implementations deal with code points (e.g. RDFlib)
<Zakim> AndyS, you wanted to mention that RDF String should not be confused with xsd:string
pfps: and consider any code point as a character
AndyS: we are making RDF strings different from xsd:strings, which have a particular definition
<Zakim> timbl, you wanted to ask about single unicode characters
AndyS: we should make sure that we do not "inherit" the restrictions of xsd:string
… the current definition of RDF string does that.
timbl: the C languages had a type for char (single quotes) and a type for strings (double quotes)
<pfps> it would be useful to find out what other RDF implementations allow all Unicode code points (i.e., permit surrogate code points)
timbl: in Python or JS, there is no such distinction. When you deal with a character in those language, it is actually a string (of length 1).
<ora> (audio is a bit choppy at this end)
pfps - Does Python accepts surrogates in UTF-8 (I think it does not)
<Zakim> gkellogg, you wanted to discuss code points vs scalar values
gkellogg: in my understanding, scalar values differ from code points in the fact that they do not include surrogate codes
<pfps> I don't know - it is hard to create a UTF-8 document that includes surrogate code points
addison: surrogate values exist to allow UTF-16 to encode code points beyon 16 bits
… they only occur as items in a string when you cut such a string in the middle of a surrogate pair
<pfps> what I did was use the \u escape, as in "\uDEAD"^^ex:foo, which was accepted in rdflib
addison: you don't need them, unless you want to preserve a single surrogate character that you would get from this kind of input.
pfps - "UnicodeEncodeError: XXX codec can't encode character '\ud83d' in position 8: surrogates no allowed." (from SO)
<pfps> what did not work in rdflib was "\U44444444"^^ex:foo, as rdflib uses Python chr to create the internal data structure
AndyS: they appear when you decode certain strings in Java
<pfps> @AndyS: what input did you use?
gkellogg: could happen when you decode '`Uxxxx` is Turtle
AndyS: you probably don't want to allow this
gkellogg: [something about IRI equality]
addison: i18n has relaxed its position about normalization
gkellogg: any feeling about not merging this? do we need a resolution?
[crickets]
gkellogg: next slide is on base direction
… we took that up in the JSON-LD WG, but we needed to resort to datatypes or using additional blank nodes
… w3c/rdf-concepts#48 adds "directional language-tagged strings" that natively have a BCP 47 language tag and a base direction
<gb> Pull Request 48 Add base direction as a fourth element of literals. (by gkellogg) [discuss-f2f] [i18n-tracker]
gkellogg: PR has been opened for a while
<pfps> indeed, my concern is that will not be sufficient
niklasl: has there been examples of this in the wild?
… today, anything from text editors to HTML display can deduce the direction.
… Do we need to specify how that should work?
<xfq> https://
addison: we have an extensive set of documents, see for example https://
… were we describe the problems if you don't have the base direction
… the guessing might get it wrong in some cases
… another situation is when you insert a string in a bigger string
… we did work to include base direction in a lot of different formats
… the key thing is: we are looking for most part of the web platform to be handle to deal with bidirection text consistently
pfps: addison, are you saying that base direction is all you need to correctly display a string?
addison: no, we need also language meta-data
pfps: language tag + base direction do not seem enough to me to get it right in all cases
addison: the base direction is used to provide isolation
… that does deal with whatever happens inside the string
… but assuming that you have a consistent string inside, the base direction ensures that you can embed it properly
[discussion about comma-separated list of opposite-direction text, and what the "right" direction is]
<Zakim> TallTed, you wanted to say I don't think we're expecting to reach perfection, more to improve on what exists without blocking future improvements. Some corner cases will remain. Anyone working with odd scripts is used to hitting such now. Fewer will be better....
TallTed: let's do not keep discussing corner cases
… we are trying to improve the existing solution, and not block future improvement
r12a: can we take this offline, I'd like to see the precise example to discuss this further
<pfps> Issue where
<niklasl> This should be a use case, which we need to prove whether base direction string metadata solves or not?
gkellogg: last issue is about BCP47 case issue; do we want to take this after the break?
addison: this one seems easy
gkellogg: the problem is: are two triples differing only by the language tag case two separate triples or a single triple?
… this raises issues for RDF C14N.
pfps - Issue: w3c/
gkellogg: no PR on this, only an issue.
addison: BCP47 is clearly made to be case insensitive
… it is perfectly valid to normalize things or to XXX
… I would not recommend people to only use the lowercase form -- many people want to make the tags pretty.
gkellogg: currently, literal term equality is term sensitive
… we could change that to make the comparison of the language tag case-insensitive
… this has consequences when you insert triples in a store
AndyS: what is the approach in XML?
… I believe there is a SPARQL test related to case-sensitivity with language tags.
… Should we push this to the meaning domain or the value domain?
addison: from what you described earlier, this is probably one triple
AndyS: then we need to decide which noramlization to use
<AZ> The fact that the lower case and upper case mean the same does not imply that they are the same tag in the syntax
<ora> Thanks Addison!
ktl: I think we have what we need from i18n, thank you very much.
… we'll continue the discussion between us.
addison: I will share some reference material
AndyS: last question about canonicalization, doesn't it change the characters in the strings? Is there a formal name for the thing that XXX?
addison: I have to look it up.
AndyS: found it, it is called "formatting"
<pfps> See w3c/
Use Cases
pfps: I will be presenting usecases. It is much better if you have a look at them yourself
… I sent out the links on the list
<TallTed> I know there's a link to the slides... could it be shared here?
pfps: 7 of them are "normal" use-cases
Peter's slides: https://
pfps: we have a couple from the people that use CIDOC-CRM, we have one that I constructed from PGs, there is a prov use case
… and we have 3 "unusual" ones.
… One for commiting deltas to RDF
… canonicalisation of language tags
… the first 5 and the 2 on the second slide have an impact on transparency
… The last 3 asks for a addition to SPARQL to show where the graph came from.
See slide conclusion from pfps
gkellogg: yes please
<Zakim> AndyS, you wanted to ask what "literal transparency" means in this context
AndyS: A clarification, what do you mean by "literal transparency?"
pfps: In the CG semantics, a quoted triple with "04"^^xsd:int does not entail "4"^^xsd:int, even though they have the same semantics.
<doerthe> q*
AndyS: Meaning, that it doesn't allow D-entailment to work inside quoted triples.
pfps: Yes. Similarly for IRIs.
… You actually need to use owl:sameAs to see that effect.
… The details of the semantics are quite a bit different than the would otherwise be.
ora: I wanted to mention that I met with developers of NGSI-LD, in the IOT/digital twins space.
… They have chosen to use labeled property graphs, but at the same time they want LD and semantics.
<enrico> bye
ora: That might yield some use cases.
pfps: There is an issue in the LPG example. The in-process standard allows multiple arcs with the same S/P/O.
<TallTed> "NGSI-LD - A graph-based context information model and API" -- https://
pfps: It would be hard to capture that in RDF (multiple edges).
… I don't think there's a way for RDF-star to fully capture Labeled Property Graphs (LPGs)
ora: We may run up against that issue.
<TallTed> "The NGSI-LD information model represents Context Information as entities that have properties and relationships to other entities. It is derived from property graphs,[14] with semantics formally defined on the basis of RDF and the semantic web framework. It can be serialized using JSON-LD. Every entity and relationship is given a unique IRI reference as identifier, making the corresponding data exportable as linked data
<TallTed> datasets."
doerthe: The biggest difference is in literals regarding transparency.
… Can you say anything about blank nodes?
pfps: The CG semantics has an unacceptional treatment of blank nodes; they are transparent.
<ktk> pfps: we lost your audio?
ktk: Regarding One-graph, are the challenging things representative?
ora: It's the LPG dilemma – no multiple RDF triples. We haven't found a solution that really solves this.
pfps: Of the semantics related use cases, seven of them use the same semantics; an odd-ball one does not.
niklasl: I think that use case is related the one I put in regarding the union of changes in an RDF graph.
<doerthe> do you still hear us?
pfps: The weird thing about use cases is that people of particular notions, and different use cases could collapse to the same requirements.
niklasl: I tried to articulate why our use case may or may not have the same semantics.
… My reasoning was to be able to use named graphs.
pfps: It may turn out than none of the difference use cases may be supported.
niklasl: That frames the relationship with LPGs
pfps: I've tried to constrain what we're looking at.
… Someone needs to examine if named graphs or graph literals would be better.
… It's something the WG can do with some use cases.
gkellogg: We said we want to do RDF Star exactly because we want to be compatible with PGs
… we should figure that out.
pfps: We should have an issue for this.
ora: When we looked at it in One Graphs, we decided we didn't want to break existing RDF semantics.
… The One Graph spec we wrote treats RDF and the other things as lower-dimensional projections of One Graph.
… It would be nice to have a real solution.
doerthe: I understand that in the normal case blank nodes are pseudo?
pfps: BNs only show up in limited cases in the use cases.
… Most peple who use CDOC-CRM use an automated opaque IRI rather than a blank node.
… I don't recall any in niklasl's cases.
… CDOC-CRM is an event-based system, which seams like an obvious use for blank nodes, but most use IRIs.
<Zakim> niklasl, you wanted to comment on "affordance"
niklasl: I use the word "affordance" in the use cases, which I think is important for us.
… Although we need uses cases for this, the ideas are based on our existing syntaxes without fully understanding the semantics.
… Named graphs, while having no semantics, have an affordance suggesting a use.
… An affordance of RDF, the uniqueness of a triple is an affordance in itself, in that it is a simplification that becomes self-evident.
… Most of use have had that knowledge for a long time.
… What worries people is that there are already differing ideas about how we want to use this.
… We need to go back and forth between the use cases and the semantics.
… Opacity is one thing, and the quoted triple another (type/token).
… If quoted triples were tokens, it would satisfy some people, but not me.
… Old school reification does have the property that different statements can be different tokens.
ora: This reminds me that I've seen a lot of "semantics by convention", where people choose a way to use RDF.
… The question in RDF-star of statements about statements is important for use to consider.
… This is a key semantics-by-convention that keeps showing up.
niklasl: I agree. One of the things that LGPs have a kind of semantics.
… I've talked with others that share this.
… One of the things I like about RDF is that the formal semantics is a very concrete surface. I can't be wrong in the semantics of XML and JSON, because there is none.
… The use cases about provenance may be a way to see what the needs really are.
ora: There is some notion of bring-your-own-semantics. LPGs are a data structure, which you can do whatever you want. Not meant to be a negative comment. But, that's not what we do with RDF.
pfps: Please send more use cases, mommy :)
AndyS: Are we drawing conclusions from the use cases?
pfps: I think the WG needs to decide what we want to support that emerges from the use cases.
fabien_gandon: The selected use cases may end up in a use case document that can be a great primer for people coming to RDF.
ora: A use case document can serve as a kind of tutorial.
… At some point, we need to decide we have all we need.
pfps: At some point, we'll say that these are the only use cases that we can completely analyse
ora: At some point, we'll need to call it and not accept new use cases.
ora: In my mind I had the idea that we should be close to done next summer.
… That's why I called for the list of things we need to do.
… Closing the collection of use cases is something we need to do at some point.
<TallTed> charter says end date is 28 August 2024... so we'd better be close to done next summer!
ora: We need to have a discussion on how to handle this.
… ktk and I will work on a master list to show the WG soon.
… Until then, we'll keep working on the things we know we need to do.
ktk: This event is very helpful and after today there should be a better understanding.
… But related to this mornings discussion, we have to try to not take more load.
ora: There are a lot of people waiting for the spec to be done.
… So far, not definite answer.
TallTed: The charter is through 28 Aug 2024, so we better be close to being done.
… We could get an extension probably. It would be helpeful to have a Gantt-chart to block out things such as publishing moratoriums.
… If you look at the months between November and March, you don't really have 4, more like 3, if that.
Dashboard
i18n
AndyS: I think we're done with I18N at the F2F.
ktk: We should ping I18N once we've added discussions to the issue.
… I believe that pfps and/or TallTed want to extend the issue with concrete examples.
TallTed: pfps had an example of an ordered list that contained directional elements.
pfps: I created w3c/rdf-concepts#61 to cover this.
<gb> Issue 61 adequacy of base direction (by pfps)
ktk: So this is what you wanted added?
pfps: Yes.
AndyS: They did ask for a concrete example.
pfps: I'll try to add some specific text to illustrate the problem
… The Unicode tech report has a descriptive example, but not specific. I believe I saw a specific example from the I18N WG.
ora: When we're addressing I18N problems, aren't these problems for others to solve?
… I'm convinced that there are problems that need to be solved.
AndyS: You can model this correctly in RDF, but people just don't.
… Statistics representation is a good example: RDF doesn't have probabilistic statements.
niklasl: I wanted to talk about literals ... I suggested the prefix in Turtle.
<timbl> (Earlier I mentioned in a discussion of RDF formats in general of Fabien's question - yes we added nested graphs to an implementation of RDF/Xml. Found it: https://
TallTed: it helps to say something isn't ours to solve if we can state the problem.
ktk: Can we set the status to done for those we're done discussing for the day?
ora: We can abuse the in-progress tag on issues.
PREFIX notation
niklasl: We suggested using "PREFIX" rather than "@prefix".
AndyS: Turtle 1.1 has PREFIX, so I thought at least for the SPARQL examples that we should start doing this. Maybe in the other RDF documents.
ktk: I support changing over our examples to use PREFIX, it will be easier for newcomers.
niklasl: Do we really want to use "PREFIX", as Turtle is more human-centric.
AndyS: "@prefix" is case-sensitive, "PREFIX" is not case-sensitive
niklasl: I'd use that as an argument for using "prefix" and "base" in Turtle.
TallTed: Then "a" should be case insensitive
Dominik_T: I like a different style, so I'll leave it as is.
AndyS: We're talking about what we write in the document, not the specification itself.
AndyS: The reason "a" exists, is that's what N3 used.
ora: I like consistency, but don't feel strongly about doing the work.
<TallTed> straw poll
TallTed: Editor's discretion is dangerous. We should have a group policy.
<ora> proposal: use PREFIX in specs over @prefix across all documents
<TallTed> +1
<ora> +1
<doerthe> +1
<Dominik_T> +1
ora: So, use "PREFIX" in preference to "@prefix" in examples?
<Tpt> +1
<AndyS> +1
<ktk> +1
<gkellogg> +1
<pfps> +1
<niklasl> +1 (but slight preference for "prefix" over "PREFIX", both over "@prefix")
<TallTed> pchampin -- please carefully delete all gb's pointers to the GitHub user `prefix`
AndyS: It might be confusing to mix PREFIX and prefix.
Tpt: If we do it for "PREFIX" we should also do it for "BASE"
Dominik_T: Do we have a page where we put together everything we've agreed on?
AndyS: We have an issue for the SPARQL documents.
gkellogg: we could add best practices to the editor's wiki
ktk: Let's add this to the wiki.
<ktk> https://
ACTION: gkellogg to add something to the wiki on conventions.
<gb> Created action #85
ktk: After lunch we have the SPARQL discussion for 1 1/2 hours.
After the afternoon break we do semantics, and if we still have time we can look at more issues.
<olaf> Do we have an online channel for remote participation? I can't seem to find it. I found a Zoom link but I am the only participant there.
<rubensworks> I think there is a break until 14:30. (I will also join via Zoom then)
<olaf> Okay, thanks for the answer! I have a meeting at 14:00 now and will try to join as soon as possible after that meeting.
SPARQL
AndyS: I would like to to through some SPARQL topics
… anyone has some more topic than what I present in the slides.
… First we have quoted triples for obvious resons.
… We have to talk about Directional language
… and Lang tag formating
… Something else is that the way timezones works changes between xpath 2 and 3
… In some cases the specification is not enough or just wrong.
… EXISTS has several issues (outlined in slides)
Link to slides: https://
<TallTed> (this applies to earlier presented decks, too)
<Zakim> TallTed, you wanted to ask that the slidedeck be added to some permanent store (as we're supposed to keep such with minutes)
AndyS: See https://
… There are related issues to that topic on sparql-dev about parametrized queries & about the LATERAL join, implemented in some stores.
… We have proposals to fix the EXISTS problem. See slides for details.
… As well as examples about the differences between the proposals.
… AndyS to pfps: Did I capture your proposal?
pfps: Yes. My proposal puts a bit more load on the query optimizer.
… Existing SPARQL implementations differ on implementation right now. Openlink Virtuoso for example differs from most other implementations.
… There are a couple of papers that show the difference between some implementations. They are probably linked somewhere in the long discussions.
AndyS: Ted, how much is the implementation in Virtuoso close to these proposals?
TallTed: I don't remember but in its core, Virutoso is a SQL implementation. Something 2000ish
ora: What does this means in pracical terms for our work?
AndyS: It is about errata, but I think it's significant so it might deserve a section.
… once we have a direction of where we go, we can proceed.
… there is already quite some material ready in sparql-dev/.
Tpt: The proposal A is much further away from what the implementation suggests right now.
niklasl: I wonder what the impact on performance will be with these proposals.
AndyS: it depends on how much it has to touch, hard to make a generic statement.
<pfps> pfps: My recent experience in Wikidata (Blazegraph) is that FILTER NOT EXISTS can be very slow. Replacing it with MINUS can sometimes run much faster. The MINUS appears to me to me more like the join (option a) version.
AndyS: I've seen oposite examples where MINUS was slower than FILTER NOT EXISTS
ora: what do we need/who do we need to talk to before we can make a decision about this.
AndyS: We might want to talk to users. I don't think we will hear much more from implementers.
ora: I am quite sure we should have enough people in our network that can give feedback to come to a conclusion.
AndyS: one point for me is compatiblity with existing spec.
… it is more a change than an errata.
pfps: my opinion is something needs to be done.
ora: I think this is clear. the question is who is talking care of it.
pfps: my suggestion is to reach out to people who wrote papers about it.
… we work on this several years in the CWG.
… At some point the WG just needs to do a decision.
… We can send them directly a message, if they don't come back that's ok too.
<Dominik_T> I can ping Renzo Angles who is one of the author of Correlation and Substitution in SPARQL
jerven: EXISTS and MINUS should be more different. I think correlated subqueries would be more different from MINUS than correlated subqueries.
ora: let's reach out to some of these people who wrote all those papers. do we know who to reach out to?
AndyS: I can find those
ora: can you andys and pfps take that on?
pfps: yes
<Dominik_T> https://
<jerven> EXISTS should as different as possible from MINUS. I think EXISTS with poposal A is more like MINUS than EXISTS with correlated subquery as a base, to investigate
gb, AndyS is afs
<gb> pchampin, I already had that GitHub account for AndyS
ACTION: pfps to follow up to the persons concerned
<gb> Created action #86
Tpt: are we gonna track changes between xml schema and xpath versions?
AndyS: the definition of comparing dates with timezones or not changed. 14h was the magic number.
<Tpt> The reason for 14h: https://
<niklasl> Dates without timezones are referentially opaque ... :|
AndyS: The other approach is to have an implicit timezone. but the question then is what is this implicit timezone.
ora: any opinions on this?
<TallTed> the ultimate implicit TZ = AoE = Anywhere on Earth. https://
gkellogg: TZ is the correct one.
ISSUE: w3c/
<gb> Created issue #87 w3c/
Small issues
https://
rdf:JSON Datatype
<Tpt> w3c/
gkellogg: it's an issue in rdf-concepts
… the datatype exists. It is just not documented in any RDF.
… it would be good to get this done.
AndyS: could you explain more about what exactly the proposal is. because RDFXML has a whole bunch of things defined around it.
… RDFXML literals can contain any fragment of XML
… I wonder if JSON would be doing the same
https://
gkellogg: The datatype is defined in JSON-LD.
… see https://
… Once it's serialized it gets canonicalized by the JSON Canonicalization Scheme (JCS)
AndyS: that is consistent with RDF HTML
gkellogg: yes
… it's just JSON, not JSON-LD
https://
ora: how much can we rely on existing specifications without reinventing a lot of things.
ora: grammar is already understood.
gkellogg: we don't have to invent it from scratch, maybe cleanout some things.
<pfps> My concern is that the value for "7" should be 7, not "7". Similarly, the value of '{ "a": 7}' should be {"a": 7}, not '{"a": 7}'.
AndyS: could we take the text from JSON and put it into RDF Concepts.
ora: We take the text from the JSON-LD spec and copy it to RDF Concepts?
gkellogg: RDF Concepts is where we talk about the other data types.
pchampin: I haven't caught up with this issue here so far. There are two issues here: The RDF Namespace & the RDF Specification.
… I don't think we need to have a 1:1 mapping.
… The datatype is totally fine but do we want to have a duplicate definition? What problem do we want to solve here?
gkellogg: We have something in the RDF Namespace that is not described in RDF Schema.
ora: It seems to me that there are two principles here. One is single source of truth, the second one is avoiding circular dependencies.
ora: Do we understand how this is supposed to work?
gkellogg: The RDF HTML does not do reference anything else, RDF XML neither.
… RDF JSON could be added similarly
… RDF XML does not reference RDF Concepts.
AndyS: I find it strange if we have some literals in RDF Concpets and others not.
pchampin: if you dereference the IRI for RDF JSON you also get the information that says "see also JSON-LD spec"
gkellogg: JSON-LD has to update to RDF 1.2 at some point. It could then also update datatypes that are defined elsewhere.
AndyS: would the JSON-Ld commuinity have strong feellings about moving the definition somewhere else?
gkellogg: my feeling is that this is not a problem. Another place might be the more natural space for it.
pchampin: my concern is to have to recommendation to formaly define that thing.
… I guess the JSON-LD WG could make a modification to the spec and declarding their own definition depricated so there might be a way forward for it.
<pchampin> if we were to reference the JSON-LD def of rdf:JSON, we would do this non-normatively, so there is no serious circular dependency problem
gkellogg: We can define an entry in RDF Schema and not create an entry in RDF concepts
niklasl: We could reference the existing definition in JSON-LD. It would also be interesting to have a space to define other datatypes.
gkellogg: Notation-3 does define its own, in its own namespace.
Dominik_T: I propose to treat it like XML
olaf: I like the idea to move away from JSON-LD.
… we might also have a separate document with datatypes so we keep the RDF Concepts document clean.
<pchampin> olaf, do you mean a REC or a Note?
<olaf> pchampin, I mean REC
ktk: I propose to add JSON as we do have "basic" types like HTML & XML. But I oppose making it easier to add other datatypes. people can do that in their own namespaces for their use-cases.
AndyS: we can also add it to the appendix of RDF Concepts.
<niklasl> +1 for Appendix
gkellogg: Moving it to an appendix would be much easier than creating its own document.
<Dominik_T> +1 for appendix, but remember about an RDFS spec
gkellogg: if we do, we should make all those datatypes non-normative
<pfps> +1 for appendix
pchampin: +1 if we an avoid creating a new document.
… Maybe appendix is a good tradeoff.
… AndyS raises a good question about what it means to be normative.
… what would it mean for a JSON-Ld spec to point to a non-normative one if we delare it as non-normative.
<pfps> JSON-LD could just say that "that non-normative bit of RDF is normative for us"
TallTed: Right now rdf:JSON is the only non-normative definition within the Datatypes section of RDF Concepts. I believe the datatypes of RDF belong in a normative section of RDF Concepts, whether Appendix or not. Given that Appendices are usually non-normative, leaving them where they are seems to make most sense.
… I don't care if it is in an appendix but in general those sections are non-normative.
gkellogg: informative changes to the spec are much easier as normative sections to a spec. This has implication on the future of a spec.
ora: I think we could have normative sections in an appendix.
TallTed: This came up somewhere else. There is an issue of having a normative section in an appendix. I can't remember where it was but we make it look like it is easy but it is not.
gkellogg: I think if we have one appendix, for example Apendix A as normative, that would be fine.
gkellogg: the easiest would be to specify RDF:JSON in the RDF Schema document. The question now is do we still mention it in RDF Concepts.
ora: The most concrete proposal is from gkellog, we could them all in RDF Concepts and then clean up the references everywhere else.
<pchampin> draft proposal: move the datatypes definitions (rdf:HTML, rdf:XMLLiteral) to an appendix in RDF concepts, and add rdf:JSON into that. Then update any reference to rdf:JSON
<AndyS> +1
<niklasl> +1 (and then plan to reference that definition of rdf:JSON in JSON-LD 1.2)
<Dominik_T> +1
<Tpt> +1
<gkellogg> +1
<ora> +1
<olaf> +1
<ktk> +1
<TallTed> +1 to putting all RDF Datatypes (unlikely, but something other than rdf:JSON might surface later) in RDF Concepts, with forward-facing errata/update/correction logged on other docs that have gap-fillers for gaps in earlier RDF specs
<pchampin> +1
Regarding "hard" things, loved one of the last posts of bblfish, which sadly died last week: https://
<pfps> +1
<niklasl> <3
RESOLUTION: move the datatypes definitions (rdf:HTML, rdf:XMLLiteral) to an appendix in RDF concepts, and add rdf:JSON into that. Then update any reference to rdf:JSON
some dicussion on the rdf:JSON datatype value space
Semantics
enrico: (slides)
… Summary of discussions and some example
<ktk> gkellogg: better?
enrico: We have a set of all choices of semantics
… TF Semantics scope: Model semantics, conservative extensions to RDF 1.1
… and a provable correct entailment "un-star" mapping to RDF 1.1
… (Examples)
… Transparent and Opaque for each of BNodes, URIs, literals
… example of opaque URis, literals, transparent bnodes and opaque properties
… example of transparent URIs, literals and blank nodes - opaque property
<AndyS> s/proeties/properties/
enrico: opaque property - keep the triple out of the current world of the graph containing the quoted triple.
… transparent property: the triple would be true/valid if asserted as well.
… locally opaque property - set of quoted triples are transparent amongst themselves but opaque outside
… "basic framework" - framework for all these different behaviours
… proposals by Antoine Zimmerman, Pierre-Antoine Champin and from Peter Patel-Schneider
… status
… not sure which form of quoted triple the WG will adopt
… extension to name graphs and quoted graphs (some proposals extend to quoted graphs)
enrico: N-ary relations => all transparent
pchampin: Q: Not clear on transparent/opaque properties
… can we build a lattice in terms of "can be a semantic extension of"?
… a way to not lock out some use cases
… a monotonic semantic extension
… possible choice criteria
… SPARQL has an equivalent ASK and matching (BGP matching defn)
… maintain the alignment SPARQL-star with simple entailment
<pfps> In my opinion, the (only) reason that SPARQL is aligned with the simple semantics is that there is no way to state non-trivial equality in the simple semantics.
enrico: BGP matching corresponds to simple entailment
… discussed last week in [SEM] TF
… agree it is important to preserve and we think it is.
<pchampin> pfps I agree, and arguably that's a feature of the simple semantics, rather than a bug
<pfps> I believe that this situation is situation remains in all of the semantics that do not change the treatment of blank nodes.
enrico: Modularity: One kind of quoted triple - for monotonicity - may need different syntax for combinations to work together.
<pfps> The difference between opacity and transparency (for literals and IRIs) is whether any non-trivial equality is carried *into* quoted triples.
doerthe: I disagree that the UCs presented by Peter did not require opacity
<Zakim> TallTed, you wanted to note that Use cases cannot *support* features. Use cases *require* features (which may or may not be supported by what we produce).
doerthe: none of them required the CG semantics, mostly because they required *literal* transparency
tallted: concerned that transparence enabling properties are "you need to remodel your dada" and will not be used.
… also concerned slides treat UCs are supporting features
… I think we can't not support 2+ cases
… also single triple only vs quoted graphs
<AZ> +1 to quoting a graph!
tallted: need to support quoted graphs else "we are doomed".
niklasl: Opacity : interact with owl:sameAs - local interpretation
… key is quoting the concept the triple represents
… transparent semantics is the single semantics
<AZ> In my opinion, if one wants to quote literally what was expressed, then one needs to litterally use literals. They are named this way for a reason. I don't see why we would need a new construct to do the same.
niklasl: don't see how to teach about opacity
enrico: About UC supporting behaviour
… UC will identify which combination of choices in the basic framework
pchampin: quoted triples - would like a more neutral name ("triple terms")
… TEP Transparency enabling properties - were intended as an example of a semantic extension on opaque triples.
… not proposing as normative - may be non-normative
… syntax -- I'm assuming abstract syntax is stable - big change otherwise
… quoted graph - big change. RDF-star is a limited extension not a big change of abstract syntax and implementations
… will quoted graphs be implemented?
niklasl: Unsure about "making triples first class counter productive" - either as route to N3 or confuses RDF
… annotations as additional information - can publish simple triples
… and have additional information for some users
… quoted triples may be a problem for the future WRT quoted graphs
enrico: what is the abstract syntax issue? Already adding quoted triple as new term type. Could have two abstract quoted triple with one concrete e.g. TEP
<Zakim> pchampin, you wanted to answer enrico
pchampin: charter of WG is to build on previous work CG and community
gkellogg: named graphs - I have an implementation of N3 based on named graphs with blank nodes.
… if there is a path to leverage the RDF 1.1 abs syntax that would be easy route
I like this idea very much
gkellogg: but for names graphs - 4th slot used for other things
doerthe: for N3 : opacity - we saw people preferred that for implementation
<TallTed> Could we retain current named graphs as transparent, and add a new "quoted"/"opaque" named graph? Might this be switchable? (e.g., Virtuoso *switchably* handles owl:sameAs and other reasoning. These are not treated as universal/permanent predicates.)
gkellogg: parsing rename for opaque blank nodes
… there are SPARQL BGP considerations (bnode transparent)
niklasl: RDF surfaces CG - graphs are typed to indicate behaviour
… need to write the relationship to named graphs
… Quoted graph may negate the need for quote triples.
… although singleton graph is not the same as the quoted triple
… area to explore is to test for usability of quoted triples vs quoted graphs
enrico: how to go on for semantics TF - waiting or the WG to fix on syntax/syntaxes and semantic choices
ora: if UC are to be the requirements, we should now show where the CG semantics does/does not apply and also what the WG needs.
<pfps> "could not" is a very strong statement - better, probably, is "could not naturally"
ora: then decide if/how UC can be built.
<niklasl> Two ways "triple terms" and "graph terms" differ: 1) the latter effectively require RDF C14N if they are to be types; 2) sharing or not of blank nodes (for triple terms I argue they are simply transparent (all in the same graph)).
doerthe: we should align to UCs
… blank nodes in SPARQL-star and see how it works.
pfps: need to be careful about strong statements
gkellogg: in SPARQL query blank nodes are like variables
<doerthe> thank you :)
AndyS: There are two cases for blank nodes; nodes in data, where the are just nodes.
… In the query syntax, there is a rule that a blank node appears just in a single BGP, so it keeps it simpler for the graph case.
… DanC had a use case where the default case was your view of the world, and named graphs were opaque.
doerthe: how does SPARQL 1.2 deal with triple and quoted triple?
enrico: Just for BGPs, a pattern corrsponds to matching and the matching using simple entailment puts the blank node back into the position in the pattern
… and simple enatailment applies. Above that, the algebra, is symbol matching.
gkellogg: same match-blank from the data is transparent
AndyS: are we, as a WG, excluding quoted graphs ?
ora: it seems to me that this discussion should be part of the discussion we need to have about named graphs
gkellogg: if there is a way to accomplish this by reusing existing constructs such as named graphs, it would get us further
gkellogg: Too early to exclude anything just yet. But if there is a way to use named graphs, then it is a low weight (wait?) for implementers and users.
<niklasl> https://
niklasl: should engage with N3-CG
… [link] graph semantics in that paper (page 6 and 7)
<AZ> There is also the RDF 1.1 Note on Dataset semantics: https://
doerthe: as particpant of N3-CG, can bring info to the WG
Small issues
specs stylesheet
ora: any small issues we can cover?
ktk: Want to resolve the mobile phone display issue
… we currently have docs with different CSS
<enrico> I have to leave. Thanks to everybody - it was fruitful!
<TallTed> +1 to ktk's interpretation of our conclusion in a telecon
ktk: apply - then gather screenshots for specific questions
<ktk> w3c/
ktk: I understood we have inconsistent CSS ... want one approach -> same CSS
pfps: some docs don't reflect the content, theer a CSS constants, and there is some CSS that is not related to the content display
ktk: do we have a definitive list of current variance?
<TallTed> w3c/
<TallTed> is the side-by-side example
pchampin: I'd like use to complete this issue. We do not have the expertise in the WG as a group.
… proposal - there is a process for translations of RECs
… not endorsed by the WG
… have a "translation" on presentation which is not the defining document
… not by this WG.
<AZ> To be sure it can stand as a translation, we can translate it to British English :)
gkellogg: too many variations - this is what CSS is for.
<TallTed> please mute if not speaking -- strong echo
gkellogg: goal should be a common subset of CSS for all docs (with local additions for certain specs that have local needs)
<pchampin> +1000 to aim for accessibility, but it seems to be that we have different notions of what's accessible/acceptable on a small screen
tallted: translation path not the way to go
… remove the fixed size constants
<pchampin> +1 to this path
tallted: then if there is a problem ask the Accessibility WG.
… mobile phones are not so important for our docs due to their size and intent
… solutions worse than the original state
… original it was a task to standardise the CSS then iterate.
<ktk> PROPOSAL: No shrinkage of fonts, roughly the same CSS everywhere, solve remaining issues with screenshots, ask accessibility WG for specific issues we can't fix.
<gkellogg> +1
<ora> +1
<TallTed> +1
<pchampin> +1
<ktk> +1
<pfps> +1
<AndyS> +0
<niklasl> +1
<doerthe> +1
<Dominik_T> -0.5
<olaf> +1
<AZ> +1
Dominik_T: don't want to discriminate against mobile phones
RESOLUTION: No shrinkage of fonts, roughly the same CSS everywhere, solve remaining issues with screenshots, ask accessibility WG for specific issues we can't fix.
Next WG meeting: Sept 21.
Next sem-TF: Sept 22.
<gb> Created action #88
<gb> Cannot create action. Validation failed. Maybe one of the names is not a valid user for w3c/rdf-star-wg?
<gb> Cannot create action. Validation failed. Maybe one of the names is not a valid user for w3c/rdf-star-wg?
<gb> Created action #89