Meeting minutes
definition of reifiers is non-normative and seems vague 1
Ora introduces the meeting.
<enrico> I will be listening from a bus the meeting of today.
<enrico> Regarding #169, I made clear my opinion in the GitHub discussion.
<gb> Issue 169 definition of reifiers is non-normative and seems vague (by rat10) [needs discussion]
ora: let's give 20 minutes each for the first two agenda items, does that work for people [yes]
tl: introduces definition of reifiers is non-normative and seems vague
tl: a related point is that I am not sure how the new reification mechanism relates to the old one
tl: the editors have different opinions on this
tl: maybe I had misunderstood something, I used the issue to ask for clarification
tl: is there a connection between the reifier and the triple as I thought?
tl: the semantics of the reifier clear?
tl: pchampin claimed the reifier refers to the triple
tl: let's clear up the semantics for the reifier
<enrico> I said literally "By convention, we call reifier the subject of a rdf:reifies triple"
<enrico> What more do you want to know??
pchampin: I disagree that the concept of reifier is insufficiently defined in the spec
pchampin: the domain is left deliberately open
pchampin: the new definition is clearer
tl: the old definition is clearer in my opinion. The new definition is vague, intentionally so
pchampin: I disagree with what you claim I said
tl: there are 2 very different opinions and I have no idea how to reconcile them
niklasl: pchampin's account is clear
tl: I am interested in what the reifier means as that is the only things we allow people to use
tl wants to better understand the model theory perspective for reifiers
enrico: the reifier refers to the triple term, a precise connection, end of story
<niklasl> +1 to enrico
<niklasl> Re. @pchampin 's comment of <some-reifer> a rdf:Statement . There's an example of that already in https://
<niklasl> Also, the discussion in issue 169 seems to veer into w3c/
<gb> Issue 152 Explain how classic RDF reification relates to triple terms and rdf:reifies (by niklasl)
ora: my worry is that this group should represent the best understanding of RDF, so what should we do about this, I trust the group to sort it out
Adrian: is this clear for the rest of the group?
<pfps> my part of the currently-silent majority feels that this has all been hashed out over and over again with no progress
ora: we can always use external validation, but I get the sense that the majority of the group doesn't agree with Thomas
<pchampin> w3c/
<gb> Pull Request 214 Clarify section about triple terms and reification (by niklasl)
pchampin: niklasl has a PR to improve the wording
pchampin: the discussion threads can be hard to follow.
pchampin: I would rather Thomas propose a PR for us to discuss
ora: we have run out of time on this agendum
gkellogg_: specs should be minimal in our spec wording.
<pchampin> +1
gkellogg_: reifiers are used across multiple syntaxes, so it makes sense to have a single definition for them to refer to
ora asks tl if he would be willing to create a PR as pchampin suggests?
tl: not really
<pfps> My view is that the request has been unclear.
tl: I haven't heard a clear answer in respect to the semantics
language strings missing a language tag 2
<pchampin> tl, as I think you pointed out, I did provide an answer to your question about the connection : w3c/
<gb> Issue 169 definition of reifiers is non-normative and seems vague (by rat10) [needs discussion]
<pchampin> unless an editor of Concepts or Semantics steps out and disagrees with me, I think you have your answer
ora: in respect to the previous topic, let's wait for external feedback
<enrico> I volunteer to create the core of a best practices note which should provide examples answering Thomas' questions
<TallTed> Conclusion of a timebox does not imply conclusion of the issue discussed therein... Timebox has expired. Further discussion on this issue should be later.
<pfps> +1
pchampin introduces the language tag issue
<ora> +1 to enrico
pchampin: I described 3 possible behaviours, and I would be happy to let parsers implement more than one of them
pchampin: gkellogg_ has a PR for n-triples that relates to option 2'
ora: I find it undesirable for parsers to quit on the first error
<pchampin> my summary: https://
gkellogg_: I was trying to layout some choices for discussion
gkellogg_: parsers vary in their behaviour
<pchampin> gkellogg_'s PR on N-Triples: w3c/
<gb> Pull Request 68 Add language to require that only valid IRIs ... (by gkellogg) [needs discussion] [spec:substantive] [test:needs tests]
gkellogg_: I am not seeing consensus on what we should agree to
AndyS: quite concerned about specifying error behavior, my suggestion is that parsers should raise the error, but the spec should leave it there
AndyS cites the Wikimedia graph as an example that has lots of errors
TallTed: we should not make RDF 1.2 parsers more strict
TallTed: it would make RDF less attractive to necomers
TallTed: let errors come up and allow people to deal with them
<pchampin> <%> <x:p> "foo"@abcdefghi, "bar"^^ rdf:langString .
TallTed: RDF graphs evolve and may have errors during that proces
TallTed: let it be lax until we decide otherwise
ora: sounds akin to XHTML, which was very strict, whilst the world wild web was not
pchampin: I don't think we are facing that problem here
pchampin talks through some examples
pchampin: we could have the spec be more relaxed
pchampin: the spec should avoid overly strict requirements on implementations
pchampin: there is a discrepancy between the syntax and the concept
<pchampin> james, the decision about ill-typed literals was "accept whetever is valid in the abstract syntax, even if semantically inconsistent"
TallTed: this is a question of where and how the error is raised
<pchampin> the problem raised her is about things that are not valid in the abstract syntax
<pfps> one point with ill-typed literals is that determining whether they are ill-typed depends on whether the datatype is recognized.
TallTed describes some clarifications
TallTed: we will have a better reception if the collision occurs at a later point when parsing a file
TallTed: when I do a SPARQL query on dirty data I won't get trustworthy results
ora: for practical reasons I want parsers to report when they detect breaches
<Zakim> TallTed, you wanted to mention "strict" vs "lax" flagging options
ora: should we endorse certain behaviors in that respect
TallTed: some parsers offer the means to set strict parsing
AndyS: the community has a general agreement on when to abort parsing
AndyS: I want to match community expectations
gkellogg_: we should use words such as MAY, as in implementations may ...
gkellogg_: let's not require any specific behavior, but at least call out the corner cases
<pfps> RDF 1.2 Triples defines a conformant N-Triples parser as one that creates an RDF graph. Changing this would be a spec change.
<TallTed> I fully support tests *and* tools that have strict/lax flags.
pchampin: gkellogg_'s PR is reasonable
<TallTed> (Virtuoso has ways to be more and less strict about what gets loaded, and about what happens when data is more and less compliant.)
ora: please take a look at gkellogg_'s PR
<gb> Pull Request 68 Add language to require that only valid IRIs ... (by gkellogg) [needs discussion] [spec:substantive] [test:needs tests]
Proposed for closing, available at 3
<pfps> Similarly for Turtle - conformance requires producing an RDF graph.
ora: why is 83 still open? Can we close it now?
AndyS: yes, as the editors agreed
TallTed: has my latest suggestion been applied?
AndyS: that was on semantics
TallTed: I see general acceptance of my PR
TallTed: don't close this just yet
gkellogg_: the language strings can be closed once we have sorted n-triples
ora: we are at the end of the call
<m2gbot> comment created: w3c/