15:49:06 <RRSAgent> RRSAgent has joined #rdf-star
15:49:10 <RRSAgent> logging to https://www.w3.org/2024/10/31-rdf-star-irc
15:49:10 <Zakim> Zakim has joined #rdf-star
15:49:30 <TallTed> meeting: RDF-star WG biweekly focused meeting
15:49:34 <TallTed> agenda: https://www.w3.org/events/meetings/e7387703-d1cb-4215-a7e1-eec9b4af24d4/20241031T120000/
15:49:34 <agendabot> clear agenda
15:49:34 <agendabot> agenda+ potential WG note explaining what we did -> 1 https://github.com/w3c/rdf-star-wg/issues/124
15:49:34 <agendabot> agenda+ Drop the requirement to support ill-typed literals with recognized datatype IRIs -> 2 https://github.com/w3c/rdf-concepts/issues/60
15:49:35 <agendabot> agenda+ Move RDF Dataset Merge to RDF Semantics or RDF Concepts -> 3 https://github.com/w3c/sparql-query/issues/155
15:49:36 <agendabot> agenda+ Additional "needs discussion" issues -> 4 https://github.com/orgs/w3c/projects/20/views/6
15:49:39 <agendabot> agenda+ Any Other Business (AOB), time permitting
15:49:44 <TallTed> RRSAgent, draft minutes
15:49:45 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/31-rdf-star-minutes.html TallTed
15:49:48 <TallTed> RRSAgent, make logs public
15:50:32 <TallTed> previous meeting: https://www.w3.org/2024/10/25-rdf-star-minutes.html
15:50:34 <TallTed> next meeting: https://www.w3.org/2024/11/01-rdf-star-minutes.html
15:55:50 <AZ> AZ has joined #rdf-star
15:57:59 <ktk> present+
15:58:04 <ktk> Chair: ktk
15:58:13 <AZ> present+
15:58:24 <ktk> AZ: is scribing working for you today?
15:58:38 <AZ> yep
15:58:42 <ktk> great tnx
15:58:46 <tl> tl has joined #rdf-star
15:59:02 <AZ> scribe+
15:59:33 <draggett> draggett has joined #rdf-star
15:59:33 <TallTed> s/scribe+/scribe: AZ
15:59:33 <TallTed> RRSAgent, draft minutes
15:59:35 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/31-rdf-star-minutes.html TallTed
15:59:49 <tl> present+
16:00:22 <draggett> present+
16:01:02 <TallTed> s/AZ: is scribing working for you today?//
16:01:02 <TallTed> s/yep//
16:01:02 <TallTed> s/great tnx//
16:01:08 <TallTed> RRSAgent, draft minutes
16:01:09 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/31-rdf-star-minutes.html TallTed
16:01:16 <TallTed> present+
16:01:48 <Dominik_T> Dominik_T has joined #rdf-star
16:02:00 <Dominik_T> present+
16:02:06 <ktk> regrets+ Ora
16:02:08 <AndyS> present+
16:02:09 <gtw> present+
16:02:11 <pfps> pfps has joined #rdf-star
16:02:25 <pfps> present+
16:02:30 <niklasl> niklasl has joined #rdf-star
16:02:39 <enrico> enrico has joined #rdf-star
16:02:44 <enrico> present+
16:03:06 <niklasl> present+
16:03:36 <AZ> ktk: Ora has a meeting so I'm chairing
16:03:45 <ktk> Zakim, open item 1
16:03:46 <Zakim> agendum 1 -- potential WG note explaining what we did -> 1 https://github.com/w3c/rdf-star-wg/issues/124 -- taken up [from agendabot]
16:03:55 <gkellogg> gkellogg has joined #rdf-star
16:04:31 <AZ> pfps: most WG do something along this line
16:04:40 <gkellogg> present+
16:04:45 <AZ> ... we haven't yet decided to do it but I think it would be a good idea
16:05:17 <AZ> ... I just noticed there is a "what's new" deliverable
16:05:32 <AndyS> 4 possible places New, primer, concepts, note - depends on the ambition - e.g. patterns and anti-patterns
16:05:53 <pfps> https://w3c.github.io/rdf-new/spec/
16:06:12 <AZ> ... In fact there is one (see URL above)
16:06:37 <AZ> ... we'll do it
16:06:43 <ktk> q?
16:07:01 <AZ> ktk: we still have to see who can work on this
16:07:10 <ktk> Zakim, next item
16:07:10 <Zakim> agendum 2 -- Drop the requirement to support ill-typed literals with recognized datatype IRIs -> 2 https://github.com/w3c/rdf-concepts/issues/60 -- taken up [from agendabot]
16:07:42 <james> james has joined #rdf-star
16:07:52 <pfps> q+
16:08:12 <AZ> q+
16:08:23 <ktk> ack pfps
16:08:24 <AZ> pfps: I agree with what Andy says in the issue
16:08:35 <AZ> ... the wording should change from MUST to SHOULD
16:08:48 <Souri> Souri has joined #rdf-star
16:08:57 <Souri> present+
16:09:12 <AZ> AndyS: it depends what "support" really means here
16:09:16 <james> present+
16:09:42 <ktk> ack AndyS
16:09:51 <AZ> ... I don't think ill typed literal making the whole graph iinvalid is very useful
16:09:58 <ktk> scribe+
16:10:30 <ktk> AZ: I also want to ask what is ment by "support". If you have a system that does not recognize a datatype IRI
16:10:41 <ktk> ... if you want to move that to another triplestore, you might loose something.
16:11:02 <ktk> ... I'm not sure what support means. It should pass as syntacticly correct.
16:11:13 <pfps> q+
16:11:13 <gkellogg> q+
16:11:16 <TallTed> s/loose something/lose something/
16:12:20 <ktk> ... By the semantics of illtyped literals, since RDF 1.1, if you have an ill-typed literal in a graph, it makes the graph inconsistent, unsatisfiable.
16:12:22 <AndyS> RDF concepts -- "The list of datatypes supported by an implementation is determined by its recognized datatype IRIs." seems to be the nearest to defining "support".
16:12:56 <ktk> ... If you say this kind of graphs may not be supported, what about other kinds of inconsistencies. Should any such graph not be supported?
16:13:15 <ktk> ... I'm not sure if I agree with this proposal.
16:13:17 <ktk> scribe-
16:13:24 <ktk> ack AZ
16:13:31 <ktk> ack pfps
16:14:02 <AZ> pfps: one option would be to tweak the wording
16:14:05 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/31-rdf-star-minutes.html TallTed
16:14:47 <ktk> ack gkellogg
16:15:18 <pfps> One option is that implementations MUST accept input documents with ill-typed literals and SHOULD include the resultant triple in the RDF graph.
16:15:19 <AZ> gkellogg: it makes no sense to talk about an ill-type literal for non-recognised datatypes
16:15:30 <AZ> ... it all depends on what "support" means
16:15:44 <TallTed> q+
16:16:04 <pfps> That is - parsing MUST NOT stop at an ill-typed literal but the system MAY choose to not include the triple in the resultant graph.
16:16:06 <AZ> ... I think the idea is to be able to only retain well-typed literals
16:16:24 <pfps> I would add that if an implementation drops the triple then it MUST produce a warning.
16:16:44 <ktk> q+
16:16:44 <AZ> ... it would be reasonable for RDF systems to not deal with ill-typed literals
16:16:45 <ktk> ack TallTed
16:17:07 <AZ> TallTed: the current text is "MUST accept", not "MUST support"
16:17:33 <AZ> ... "accept" means it can evolve
16:17:47 <AZ> ... triplestores should be able to take any literals
16:18:18 <AZ> ... but then it may deal with the literal for some processes adequatel
16:18:49 <AndyS> q+
16:18:50 <james> q+
16:18:54 <AZ> ... you can do almost anything with RDF and unless there is a strong argument against that, we should keep it like this
16:19:21 <AZ> ktk: how are different implementations dealing with this?
16:19:24 <ktk> ack ktk
16:19:58 <Souri> q+
16:20:20 <AZ> AndyS: in SPARQL, there are cases when you need to assign a value, so it does not work with ill-typed literals but that a SPARQL process
16:20:26 <ktk> ack AndyS
16:20:42 <AZ> ... there could be wording to make this a little more flexible with "MAY"
16:20:53 <AZ> ... it's difficult to make it a "MUST"
16:20:59 <pfps> agreed that it is difficult to require a warning
16:21:22 <AZ> james: We are very accepting (in our implem) and it has been very useful
16:21:43 <ktk> ack james
16:21:47 <AZ> ... I think it should be a "MUST" for reasons of interoperability
16:21:54 <ktk> ack Souri
16:21:55 <AndyS> "SHOULD accept" -- MUST for warnings is a bit strange. We don't have a "warning" mechanism in the specs.
16:21:57 <AZ> ... but it's personal opinion
16:22:42 <AZ> Souri: when we find an illtyped literal, we separate it
16:23:05 <AZ> ... we continue even if we find error and they get reported
16:23:27 <AndyS> q+
16:23:27 <AZ> ... we do not accept it in that form, so for us, a MUST would not work
16:23:28 <TallTed> q+
16:23:57 <AZ> AndyS: choosing the datatypes you choose to handle is something you do when you use the data
16:24:04 <ktk> ack AndyS
16:24:07 <AZ> ... at loading time, you may not have decided
16:24:43 <AZ> TallTed: I'm concerned to hear that some implementations are not conformant
16:25:00 <Souri> q+
16:25:03 <pfps> q+
16:25:05 <ktk> ack TallTed
16:25:10 <AZ> ... It's blocking evolution, because there may be new datatypes supporting in the future
16:25:39 <james> q+
16:25:45 <AZ> ... The reasoning I see is that the proposal is done because there are implementations that are not conformant
16:26:12 <niklasl> +1 for evolution (with the caveat that I prefer opt-in "drop unrecognized" modes to avoid sending inexplicable data onward).
16:26:14 <pfps> q+ to say that implementations that reject unrecognized datatypes are broken but ones that do not fully accept known ill-typed literals are not so bad
16:26:19 <ktk> ack Souri
16:26:42 <pfps> q- because Souri covered my poin
16:26:58 <AZ> Souri: if we have an xsd:integer with "abc" lexical form, we don't accept it, but if you have ex:mytype, we don't do anything
16:27:22 <ktk> q?
16:27:35 <AZ> ... we report the problem and users can decide what to do with this problem
16:27:38 <ktk> ack pfps
16:27:38 <Zakim> pfps, you wanted to say that implementations that reject unrecognized datatypes are broken but ones that do not fully accept known ill-typed literals are not so bad
16:27:41 <ktk> q?
16:28:17 <ktk> ack james
16:28:38 <AZ> james: we do 2 kind of things, one on the values to do efficient operation, and one that just take any literal transparently
16:29:08 <AZ> ... in the past, we did not do anuything with time, then it evolved to handle it appropriately
16:29:28 <ktk> q?
16:29:54 <AZ> ktk: what do we do with this issue? We don't really have a conclusion
16:29:56 <TallTed> "MUST accept" is current text
16:30:26 <Souri> q+
16:30:40 <ktk> ack Souri
16:31:13 <AZ> Souri: in Oracle, we don't want to have, e.g., 31st February, so we reject it
16:31:24 <TallTed> q+
16:31:48 <AZ> ... we do not hide it, we report it
16:32:01 <tl> q+
16:32:26 <AZ> ... I would not like to have "MUST accept"
16:32:43 <ktk> ack TallTed
16:32:43 <AndyS> q+
16:33:18 <AZ> TallTed: not accepting data is bad but you can handle the ill-typed literals after they are loaded
16:33:57 <Souri> q+
16:34:22 <AZ> ... in the future, there could be a change that makes a lexical form acceptable
16:34:56 <ktk> ack tl
16:35:25 <AZ> tl: I like the idea that there are several phases, 1st you parse and put in store, then other processes
16:35:48 <AZ> ... then the user can be informed of problematic literals
16:36:14 <AZ> ... you would get an error if you use reasoner on the data
16:37:03 <AZ> AndyS: I find the use cases of rejecting or not rejecting both reasonable
16:37:28 <AZ> ... the problem is when an entire graph is rejected
16:37:35 <ktk> ack AndyS
16:38:16 <AndyS> My pref is change "MUST accept" to "SHOULD accept". All the described handling cases seem reasonable for their different cases.
16:38:17 <ktk> ack Souri
16:38:19 <AZ> Souri: w do not reject entire graph, just the triples with ill-typed literals
16:38:47 <Dominik_T> +1 for SHOULD
16:38:49 <AZ> ... the earlier the problems can be pointed out the better
16:39:07 <AZ> ... customers are also happy with this
16:40:09 <ktk> Strawpoll: "Implementations MUST accept ill-typed literals" gets changed to "Implementations SHOULD accept ill-typed literals"
16:40:15 <Dominik_T> +1
16:40:16 <gtw> +1
16:40:19 <ktk> +1
16:40:20 <pfps> +1
16:40:21 <AndyS> +1
16:40:26 <Souri> +1
16:40:26 <gkellogg> +1
16:40:33 <AZ> -0.3141592
16:40:33 <enrico> 0
16:40:44 <TallTed> -0.5
16:40:52 <james> 0
16:40:53 <TallTed> q+
16:40:58 <niklasl> +0.5 (I might prefer some "SHOULD by default, MUST if asked to accept"...)
16:41:32 <AndyS> q+
16:41:33 <niklasl> q+
16:41:38 <ktk> ack TallTed
16:41:42 <AZ> TallTed: if we make this change, we have to be really clear how errors are dealt wit
16:41:49 <AZ> s/wit/with/
16:42:18 <AZ> AndyS: I don't think we should go into how errors and warnings are handled
16:42:35 <TallTed> An ill typed literal is not a syntax error.
16:42:36 <ktk> ack AndyS
16:42:59 <TallTed> An ill typed literal conforms to syntax.
16:43:03 <Souri> +1 to AndyS
16:43:04 <AZ> ... there's an historical example (??) where specs mentioned what to do with errors and it took a large space, and was eventually dropped
16:43:10 <ktk> ack niklasl
16:43:58 <AZ> niklasl: I had experienced cases of systems that reject things that I would have like be accepted because things evolved
16:44:14 <AZ> ... although I'm sympathetic to the arguments (thus my +0.5 vote)
16:44:33 <AZ> ... it could be something that users can opt-in or out
16:44:54 <ktk> q?
16:45:11 <AZ> ktk: there could be a note that explain what pitfalls etc occur and how to deal with them
16:45:22 <ktk> Zakim, next item
16:45:22 <Zakim> agendum 3 -- Move RDF Dataset Merge to RDF Semantics or RDF Concepts -> 3 https://github.com/w3c/sparql-query/issues/155 -- taken up [from agendabot]
16:45:26 <AZ> ... we can continue this offline
16:46:12 <AZ> gkellogg: not a strong opinion, but RDF Semantics seams the right place for this definition
16:46:52 <AZ> ... this is currently defined in SPARQL Query
16:46:58 <gkellogg> https://github.com/w3c/sparql-query/pull/152#discussion_r1735203153
16:46:59 <gb> https://github.com/w3c/sparql-query/pull/152 -> Pull Request 152 Use RDF Dataset definition from RDF Concepts (by rubensworks) [spec:substantive]
16:47:11 <pfps> q+
16:47:35 <AZ> pfps: I don't see a problem about putting it in RDF semantics
16:47:46 <ktk> ack pfps
16:48:00 <AZ> ... it makes sense to have a section on dataaset merging in smenatics
16:48:05 <enrico> +1 to pfps (add to section 10)
16:48:12 <AZ> s/dataaset/dataset/
16:48:23 <AZ> s/smenatics/semantics/
16:48:33 <ktk> q?
16:48:37 <AZ> pfps: graph merge is in semantics
16:48:48 <TallTed> +1 to putting Dataset Merge in same document as Graph Merge
16:48:53 <niklasl> https://www.w3.org/TR/sparql12-query/#sparqlDataset "Definition: RDF Dataset Merge"
16:48:57 <pfps> it would likely go in section 10.
16:49:32 <AndyS> https://www.w3.org/TR/sparql12-query/#sparqlDataset
16:49:44 <AZ> pfps: don't close the issue until we have a proposed content
16:49:59 <enrico> Document RDF semantics section 4.1Shared blank nodes, unions and merges
16:50:23 <AZ> ktk: 5 min left, let's jump to AOB
16:50:34 <TallTed> s/4.1Shared/4.1 Shared/
16:51:09 <AZ> enrico: I want to look at the writing in RDF 1.2 Semantics
16:51:31 <AZ> ... what's the process for updating the doc
16:52:36 <AZ> ktk: Semantic TF tomorrow is also 1 hour earlier for the Europeans
16:52:53 <TallTed> RRSAgent, draft minutes
16:52:55 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/31-rdf-star-minutes.html TallTed
16:57:08 <ktk> s/anuything/anything/
16:57:14 <ktk> s/iinvalid/invalid/
16:57:23 <ktk> s/illtyped/ill-typed/
16:57:33 <ktk> s/smenatics/semantics/
16:57:37 <ktk> s/syntacticly/syntactically/
16:57:53 <ktk> s/seams/seems/
16:58:05 <ktk> RRSAgent, draft minutes
16:58:07 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/31-rdf-star-minutes.html ktk
16:59:47 <ktk> Zakim, leave
16:59:47 <Zakim> leaving.  As of this point the attendees have been ktk, AZ, tl, draggett, TallTed, Dominik_T, AndyS, gtw, pfps, enrico, niklasl, gkellogg, Souri, james
16:59:47 <Zakim> Zakim has left #rdf-star
16:59:53 <ktk> RRSAgent, leave
16:59:53 <RRSAgent> I see no action items