Meeting minutes
ktk: Ora has a meeting so I'm chairing
potential WG note explaining what we did 1
pfps: most WG do something along this line
… we haven't yet decided to do it but I think it would be a good idea
… I just noticed there is a "what's new" deliverable
<AndyS> 4 possible places New, primer, concepts, note - depends on the ambition - e.g. patterns and anti-patterns
<pfps> https://
pfps: In fact there is one (see URL above)
… we'll do it
ktk: we still have to see who can work on this
Drop the requirement to support ill-typed literals with recognized datatype IRIs 2
pfps: I agree with what Andy says in the issue
… the wording should change from MUST to SHOULD
AndyS: it depends what "support" really means here
… I don't think ill typed literal making the whole graph invalid is very useful
AZ: I also want to ask what is ment by "support". If you have a system that does not recognize a datatype IRI
… if you want to move that to another triplestore, you might lose something.
… I'm not sure what support means. It should pass as syntactically correct.
… 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.
<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".
AZ: If you say this kind of graphs may not be supported, what about other kinds of inconsistencies. Should any such graph not be supported?
… I'm not sure if I agree with this proposal.
pfps: one option would be to tweak the wording
<pfps> One option is that implementations MUST accept input documents with ill-typed literals and SHOULD include the resultant triple in the RDF graph.
gkellogg: it makes no sense to talk about an ill-type literal for non-recognised datatypes
… it all depends on what "support" means
<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.
gkellogg: I think the idea is to be able to only retain well-typed literals
<pfps> I would add that if an implementation drops the triple then it MUST produce a warning.
gkellogg: it would be reasonable for RDF systems to not deal with ill-typed literals
TallTed: the current text is "MUST accept", not "MUST support"
… "accept" means it can evolve
… triplestores should be able to take any literals
… but then it may deal with the literal for some processes adequatel
… you can do almost anything with RDF and unless there is a strong argument against that, we should keep it like this
ktk: how are different implementations dealing with this?
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
… there could be wording to make this a little more flexible with "MAY"
… it's difficult to make it a "MUST"
<pfps> agreed that it is difficult to require a warning
james: We are very accepting (in our implem) and it has been very useful
… I think it should be a "MUST" for reasons of interoperability
<AndyS> "SHOULD accept" -- MUST for warnings is a bit strange. We don't have a "warning" mechanism in the specs.
james: but it's personal opinion
Souri: when we find an ill-typed literal, we separate it
… we continue even if we find error and they get reported
… we do not accept it in that form, so for us, a MUST would not work
AndyS: choosing the datatypes you choose to handle is something you do when you use the data
… at loading time, you may not have decided
TallTed: I'm concerned to hear that some implementations are not conformant
… It's blocking evolution, because there may be new datatypes supporting in the future
… The reasoning I see is that the proposal is done because there are implementations that are not conformant
<niklasl> +1 for evolution (with the caveat that I prefer opt-in "drop unrecognized" modes to avoid sending inexplicable data onward).
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
… we report the problem and users can decide what to do with this problem
<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
james: we do 2 kind of things, one on the values to do efficient operation, and one that just take any literal transparently
… in the past, we did not do anything with time, then it evolved to handle it appropriately
ktk: what do we do with this issue? We don't really have a conclusion
<TallTed> "MUST accept" is current text
Souri: in Oracle, we don't want to have, e.g., 31st February, so we reject it
… we do not hide it, we report it
… I would not like to have "MUST accept"
TallTed: not accepting data is bad but you can handle the ill-typed literals after they are loaded
… in the future, there could be a change that makes a lexical form acceptable
tl: I like the idea that there are several phases, 1st you parse and put in store, then other processes
… then the user can be informed of problematic literals
… you would get an error if you use reasoner on the data
AndyS: I find the use cases of rejecting or not rejecting both reasonable
… the problem is when an entire graph is rejected
<AndyS> My pref is change "MUST accept" to "SHOULD accept". All the described handling cases seem reasonable for their different cases.
Souri: w do not reject entire graph, just the triples with ill-typed literals
<Dominik_T> +1 for SHOULD
Souri: the earlier the problems can be pointed out the better
… customers are also happy with this
<ktk> Strawpoll: "Implementations MUST accept ill-typed literals" gets changed to "Implementations SHOULD accept ill-typed literals"
<Dominik_T> +1
<gtw> +1
<ktk> +1
<pfps> +1
<AndyS> +1
<Souri> +1
<gkellogg> +1
<AZ> -0.3141592
<enrico> 0
<TallTed> -0.5
<james> 0
<niklasl> +0.5 (I might prefer some "SHOULD by default, MUST if asked to accept"...)
TallTed: if we make this change, we have to be really clear how errors are dealt with
AndyS: I don't think we should go into how errors and warnings are handled
<TallTed> An ill typed literal is not a syntax error.
<TallTed> An ill typed literal conforms to syntax.
<Souri> +1 to AndyS
AndyS: there's an historical example (??) where specs mentioned what to do with errors and it took a large space, and was eventually dropped
niklasl: I had experienced cases of systems that reject things that I would have like be accepted because things evolved
… although I'm sympathetic to the arguments (thus my +0.5 vote)
… it could be something that users can opt-in or out
ktk: there could be a note that explain what pitfalls etc occur and how to deal with them
Move RDF Dataset Merge to RDF Semantics or RDF Concepts 3
ktk: we can continue this offline
gkellogg: not a strong opinion, but RDF Semantics seems the right place for this definition
… this is currently defined in SPARQL Query
<gkellogg> https://
<gb> Pull Request 152 Use RDF Dataset definition from RDF Concepts (by rubensworks) [spec:substantive]
pfps: I don't see a problem about putting it in RDF semantics
… it makes sense to have a section on dataset merging in semantics
<enrico> +1 to pfps (add to section 10)
pfps: graph merge is in semantics
<TallTed> +1 to putting Dataset Merge in same document as Graph Merge
<niklasl> https://
<pfps> it would likely go in section 10.
<AndyS> https://
pfps: don't close the issue until we have a proposed content
<enrico> Document RDF semantics section 4.1 Shared blank nodes, unions and merges
ktk: 5 min left, let's jump to AOB
enrico: I want to look at the writing in RDF 1.2 Semantics
… what's the process for updating the doc
ktk: Semantic TF tomorrow is also 1 hour earlier for the Europeans
<ktk> s/smenatics/semantics/