<pchampin> scribe: gkellogg
<pchampin> https://github.com/w3c/rdf-star/issues/40
pchampin: Just the long-standing action the test suite…
afs: I have an action on summarizing the syntax issues.
pchampin: I’ll add an issue so it shows up in the list.
... There was a PR on the test suite, but it was merged, as it didn’t seem to require call time.
... There were some new tests around combinations of embedding. Further PRs are welcome.
<pchampin> https://github.com/w3c/rdf-star/pull/75
<gatemezing> s/Present + / present+
pchampin: I’ve seen some comments on the PR discussions. pfps has raised a number of issues, and thomas one I haven’t seen yet.
thomas: I like that it’s more prominent in 2.1 and not just the appendix. I think the seminal example should be explained at the top in 2.1 and why it doesn’t work.
... There’s also the relationship to RDF refication, which should be more prominant in sect 2.
... So that people coming to RDF* thinking it solves their problem will be well informed without needing to fully understand the semantics.
... It took a while to understand these bits, and the spec should be clear.
pchampin: The overview section now has an example, and another in 2.1.
... As pfps pointed out, the spec doesn’t require people to have read the initial papers, and should be self-suficcient. Starting with a bad example and explaining why it is bad doesn’t seem like a good way to start.
thomas: I think 2.1 is fine, just make it clear where rdf* stands WRT reification.
pfps: I disagree with thomas and think the semanal example should be relegated. The Appendix is far to kind to the seminal example, and it should be stated as such. The example was wrong and misleading.
... Lets say that and move on.
pchampin: I’m sorry olaf can’t be hear to make a case. I’ve stated that I’m not as harsh on the example.
pfps: THere’s evidence to bvack up my statement: multiple people are confused if RDF* has unique triples.
pchampin: But, there are a number of people that were not so misled.
... The so-called “seminal-example” is the running example used in the original papers. It’s copied into the current spec.
<pchampin> https://pr-preview.s3.amazonaws.com/w3c/rdf-star/pull/75.html#the-seminal-example
<pfps> The example is the one in http://ceur-ws.org/Vol-1912/paper12.pdf
pchampin: The problem with the example is that it gives the impression that the <<…>> embedded triples represent ocurances of triples. Not an occurance of the triple in some document.
... IMO, the definitions say it’s the abstract triple, and not the ocurance.
ora: iin writing a spec, our goal should be confusion-free. WIthout expressing my opinion, I agree that it’s confusing.
<TallTed> Perhaps we could just say "The world has turned. Original documents were problematic in various ways. We have not reproduced the problematic parts here because they were problematic and we don't want to continue those problems." and then actually leave out the problematic parts...
<pchampin> STRAWPOLL: change the wording in appendix A.2 to more clearly disqualify the seminal example as "bad"
<pfps> +1
<thomas_> -1
+1
<pchampin> -0.5
<AndyS> +0
ora: you want the example to not only not be in any future spec, but characterize the previous use as “bad”.
<james> +1 : present and indicating the meaning
<gatemezing> gatemezing: q+
pchampin: I thought it was important to acknowledge that the previous documents were misleading. THe idea was to try to fix the damage that was done and that the community has evolved.
TallTed: I noted on one of the issues that the original document should be relegated to history. It was a solo effort and made some errors. We don’t need to reproduce anything from it, other that to say it’s historical.
pchampin: That’s the title of the appendix. I think it’s better to have this recorded near the spec, rather than burried in an archive.
<gatemezing> +1 to TallTed, without any mention of "bad" or whatever
TallTed: Olaf agreed. We shouldn’t reproduce anything problemantic, other than to say that something previous was problemantic.
ora: I agree, let’s not reproduce it or signal it out. Historical documents are exactly that and shouldn’t be given additional relevance.
TallTed: The spec is a produce of a group, where we can strive for perfection.
james: I oppose this; the document will be found and will be misleading unless there’s another document that repudiates it,
TallTed: Iagree to have a reference to another document which repudiates the previous doc.
james: As long as it’s clear that we say these documents don’t agree. If there’s another document that says why it is wrong, you’re accounting for it.
thomas_: The appendix was a way to understand the relationship with reification. We’ll need to come back to that and explain how this relates to other versions such as RDF reification.
pchampin: I’m a bit unconfortable with the way we’re going. I don’t feel the spec is fundmentally different from the original paper. I still think that the core of the paper is aligned with the spec.
... I understand the arguments, but the problems didn’t prevent this group from happending.
... The example is misleading, but there is much else in the paper which is relevant.
thomas_: The original paper has two different versions, the semantics and the example. THis was just until recently.
ora: once the new spec is out, does one need to read the older papers? W3C has a long history of publishing new, sometimes very different versions and that it supercedes the previous work.
... I don’t think we need to do more than that.
AndyS: I’m in the same place as Ora; we should say it is superceded and we don’t need to explain it.
TallTed: This supercedes what came before. It was an input and we don’t need to re-explain anything in it.
... We can’t put warnings on the old documents, because they are PDFs. We need to make this document solid.
james: I want to reiterate that because you think you need to refer to it, is wrong. If I see a document with new semantics, I ignore the old semantics. You shouldn’t require the previous document in order to understand the spec.
<thomas_> +1 to james
pchampin: I agree on that. That being said, we can say that it is superceded.
james: “Don’t read this paper!”
pchampin: Don’t expect to find consistency between the paper and the spec.
<pchampin> ACTION: pchampin to get back admin priviledge on BBB, or find another platform
gatemezing: Another option would be to say that someone could write a paper that states that there was something misleading before we get to the output of this group.
<pchampin> STRAWPOLL: replace appendix A.2 by a sentence in the introduction explaining that seminal papers are not entirelt aligned with the spec
<james> -1
<pchampin> -0.5
<thomas_> -0.5
AndyS: Just say that the editor understands the concerns and move on.
<ora> 0 (just not sure yet)
<TallTed> +0 strawpoll
<TallTed> +1 AndyS
<gatemezing> gatemezing: +0
pchampin: I’ll keep the appendix and try to make the language more explicit without being dismissive.
... Otherwise, we have a point by thomas_ to improve 2.1.
pchampin: I understand that this is a technical topic that not everone wan’t to go into in too much detail.
... To make the call time more productive, I wanted to validate by closing some issues.
<pchampin> https://github.com/w3c/rdf-star/issues/37
pchampin: This is a syntactice sugar issue. There are some choices in the proposal.
... There was an agreement to make RDF* syntactic sugar on RDF reification, so that the semantics is not something new, by mapping RDF* syntax to RDF syntax.
... it’s ot possible to map RDF* syntax to RDF syntax.
... We can say there exist IRIs to do the mappings, but we don’t give them.
AndyS: I like the approach, and not to be able to write it “raw” in RDF Turtle.
thomas_: Is this an optimization? Shouldn’t we do that for lists and other complex constructs.
pchampin: I think the same approach could have been taken for Lists. The idea is to alow implementors to optimize it without having to handle the bad implications.
AndyS: If the users can break the assumptions, they will do so.
pfps: I disagree with both: I prefer the semantic approach in the original “ash can” document, partly because it relates back to RDF reification.
... I like the ability to describe parts of triples and have more freedom to fidle with it using RDF reification.
pchampin: That freedom is what we’re trying to avoid :)
... There was not a 1-1 mapping between RDF* and reification.
pfps: You could use the nice new syntax if it was useful, but you could also go from that to other kinds of RDF reification and have them inter-relate. The new syntax gives us two different styles. One is wide-open, but the other is a useful subset; you can’t easily go from one to the other.
... You could, if you wanted to relate the two.
pchampin: Is that something you’d like to include in the spec
pfps: If it turns out that the new view of reification is what’s in RDF*, it would be good to relate it back to the old view; but, I don’t think it’s necessary.
AndyS: I think mapping from RDF* into “full reification” is the way to do it. Whether from new semantics or directly embedded semantics.
... We might want to write something about transforming from one to the other.
pchampin: There’s also an issue about named graphs, and we should have an appendix exploring the relations and differences.
<pchampin> STRAWPOLL: are you ok with "abstract syntactic sugar", i.e. being unable to serialize RDF* in plain Turtle / RDF-XML / etc...
<pchampin> +1
<AndyS> +1
<ora> +1
+1
<gatemezing> +1
<james> -1
<pfps> +0.5 I would prefer not extending the abstract syntax but I'm OK with an abstract-to-abstract mapping
<thomas_> -0
<TallTed> this does appear to force new MIME types and file extensions...
<TallTed> +0
<AndyS> Disagree - as per issue discussion.
<pchampin> https://github.com/w3c/rdf-star/issues/43
TallTed: It’s important to cover the rough implications of a decision such as this.
<pfps> But doesn't RDF* itself require a new MIME type? Isn't just the <<>> syntax enough for a new MIME type?
james: I’m turning out to be the oly RDF purist, apparently. I don’t think you should have to chase afte rnew mime types.
... If at some point there is a clear semanics, I’m willing to consider new mime types. But not until I understand that.
<AndyS> MIME types are not automatically strict - c.f.XML, HTML.
<james> pfps: YES
pchampin: Do you consider that the current semantics is not clear enough?
james: If there were clear semantics I could implement it. If it does entail a new mime-type, I’d be comfortable if it could be represented using existing mime-types.
pchampin: There is a clear way. We say there is an IRI, but don’t give it, then you can implement it that way. You can’t expect anyone else to understand it.
james: Then you undercut interoperability.
AndyS: Mime-types don’t guarantee semantic interoperation.
... There is a translation that can be made to RDF.
<pchampin> ack: pfps
pfps: I’m confused: <<>> requires a new MIME type, right?
AndyS: It’s not automatic, it’s one option.
... Old data is not invalidated.
<gatemezing> Re AndyS : that's why there are people working on syntaxis interoperability
AndyS: If we’re going to anticipate that it will change again we might not create a mime-type.
<TallTed> IANA might beg to differ
AndyS: TallTed I think that’s a big claim. Profiles are one way this has been done.
<thomas_> still I'm not sure this whole thing is not premature optimization
AndyS: You haven’t changed the meaning of a document by adding new syntax, because the worst that can happen is that you fail. Two implementations won’t interpret differently.
... If you have old data, what is the mime type? You might need to look at the entire document before you assign a mime type,
ora: Before supporting RDF* and I see the mime type, I think I can parst it, but I can’t.
AndyS: Who’s responsibility is it?
ora: if there’s a new syntax there should be a new mime-type.
AndyS: Then you have the consideration if you don’t know. Are you going to lock out old clients because somewhere it may happen.
... Please give feedback on the issues.
<TallTed> Regrettable decisions were made a long while back about not including any info within the file about what it is, e.g., `Turtle 1.0` vs `Turtle 1.1` vs `Turtle* 1.0`
<TallTed> JSON-LD now has a declaration within the file about being 1.0 vs 1.1