23 April 2021


AndyS, gkellogg, james, pchampin, TallTed, thomas
James Anderson, Olaf Hartg, William Van Woensel

Meeting minutes

Announcements and newcomers

pchampin: Not too much feedback from the tweets and anouncements of the updated draft.

Open actions

<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction

pchampin: No open actions at the moment

gkellogg: I had an action to reorganize the concrete syntaxes, which is done.

Old or new media-types for RDF-star

Open PR #149 - splitting manifets

andys: not really technical, just organizational

pchampin: I want to discuss the media-type issue.

<pchampin> https://github.com/w3c/rdf-star/issues/43

<pchampin> https://github.com/w3c/rdf-star/issues/43#issuecomment-814772066

pchampin: We need to answer two separat equestions.
… first, if we had the authority to update existing media types, would we want to update them with rdf-star features, or would it be better to have a new separate media type.
… If we think the right way is to update existing media types, would we want to create an interim media type?

james: Or, do we want to be in a position to flagrantly abuse the exising media types.
… There’s nothing in the process that permits us to do it, but nothing to stop us.

pchampin: I’ve been assuming that our answer to the first question is “yes”

james: If it gets to be a TR, it has the authority to claim the space. Until then, it can’t.
… My answer to the first question is that if there were a WG that produced a TR, it would be appropriate.

pchampin: Some people might disagree.

<pchampin> STRAWPOLL: do we consider that eventually, text/turtle (and other media-type covered by our CG-spec) should be update to include RDF-star features?


<pchampin> +1

<AndyS> +1

<james> +1

<pchampin> eventually meaning "by a WG having this authority"

<TallTed> "text/star+turtle"... except that Turtle is not a viable fallback, because Turtle-star is not a subset of Turtle

<TallTed> text/turtle was unfortunately written not to include a version declaration, and adding one now would break existing tools as much as including Turtle-star data in text/turtle

<TallTed> -0.8

gkellogg: Groups abuse media types all the time, whill in progress.

TallTed: The problem starts with groups that don’t have a statement about dispersing datatypes.
… Putting turtle-star into text/turtle will break things.
… THe only good answer is to presume there will be a new mediatype and act that way.
… You build it in the spec and send it in for registration.
… The only good thing is to register a new media type.

AndyS: Postel’s law on production and consumption.
… Note that text/turtle was not done by the WG, but precedes that. so what came out as Turtle is different than the originally proposed registration.
… Registrations can be changed, which might not be what expected, but it happens.
… PREFIX/@prefix, charset, ...
… THere are people who extend sparql, and still use the regular media type.

AndyS: Is there a use case where an updated processor would not want to receive turtle-star data?
… On the discussions, this has been posed, but noone’s described a use case.
… Whatever we do, there are going to be pain points.

james: I agree with Andy that it’s possible to change things. THis requires the authority to change the document which defined it.

AndyS: The only thing we can do is propose changes.
… The entire document has no standing in process.

james: When there was a transition from SPARLQ 1.0 to 1.1, the language changed. There weren’t any requests to distinguish between them.

AndyS: There was never a discussion of changing the mime-type.

james: Going back to the question about breaking things. it’s concieveable that we could have proposed enodings which conform to text/turtle, but we didn't.
… We might want to say why we didn’t chose to conform with the existing syntax.

pchampin: We could have encoded RDF-star in something which is still valid Turtle. (proposition)

james: The group decided that the turtle-star encoding has advantages that overweigh this. That should be mentioned somewhere.
… Why didn’t we just use the reification vocabulary?

<TallTed> Eric Prud'hommeaux, the contact person for text/turtle, is in this group (regularly comments on github, though he doesn't often if ever join calls) -- https://www.iana.org/assignments/media-types/text/turtle

<TallTed> and he has failed to update that doc from pointing to https://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/ to http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110328/ nor to http://www.w3.org/TR/2014/REC-turtle-20140225/

pchampin: Given that Turtle has no “extension-points”, that could have been the place to do it.
… We might have considered that theoretically.

gkellogg: It’s IANA’s fault. We should have sn IANA section to describe proposed changes and our rationalle.

thomas: One thought was to base everything in reification.

<AndyS> Reasons against (one use per triple) reification: (1) too many triples (this is in RDF-star section 2.1) (2) partial ("broken") reifications.

pchampin: I think that Peter’’s preferred way was to not have a different abstract syntax.

thomas: The thought was to express the semantics of RDF-star through reification.

pchampin: I think he would have preferred RDF-star to be another language which is logically equivalent to using reification.

<AndyS> Also (and is in sec 2.1) - query in SPARQL is cumbersome -- obv can be solved by extending SPARQL syntax only ... which is where the original <<>> came from in DAWG days.

pchampin: We broke turtle with << >>.

thomas: We could have formulated it in a way that a standard turtle processor could have understood it.

pchampin: I really don’t see a way to do that, but we maybe didn’t spend enough time on that.

thomas: I think we should go for x- mime types to make it clear that this is a proposal.

pchampin: That’s the second question.
… There is a (small) majority that agreed to extend the existing languages.
… In the mean-time, what do we suggest people do?

<pchampin> STRAWPOLL: assuming we recommend to update text/turtle (and other mimetypes), do we recommend people to use the original original mimetype for RDF-star content?

<pchampin> +1

<TallTed> straw poll doesn't need to be yes/no question. can be options (1) (2) (3)

<thomas> -1

<james> +0

+1 but with caution

<TallTed> -0.9

<AndyS> +1

<TallTed> I'm not a full block, but strongly against. I think this question needs to reach a broader audience -- at least all of RDF-DEV CG, beyond rdf-star-cg

pchampin: It’s fair that we have an IANA section to propose extending the types. It’s what do we do in the mean time?

<pchampin> gkellogg: there is no good solution, we need to caution people on the use of these format in production systems

<pchampin> ... while the profile parameter is not normatively ok, it could be a good option

<pchampin> ... we need to stay away from creating a new text/x-... mimetype; it has been shown to be an anti-pattern

thomas: How is it not an anti-pattern to publish text/turtle that it’s turtle?

AndyS: There are two sides to that.

james: what has the expeirence been with using wild headers? (I.e., that aren’t registered? If a server understool something like X-EXTENSION: turtle-star,
… A server that understands that would serve it one way, and if it didn’t it would ignore it.
… Servers would ignore an unregistered header.

AndyS: That would cover the case of clients who are aware of it but don’t want it.
… When we went through RDF/SPARQL 1.1, I don’t remember there being particular difficulties.

<TallTed> text/star-turtle would be legal albeit potentially confusing ... text/turtle-star likewise

<TallTed> text/star+turtle fails because Turtle-star is not subset of Turtle

<TallTed> *is* legal to do Link: rel=alt from ttl-star to ttl (or vice-versa)

<TallTed> or use con-neg preference values ... which requires the different media type

AndyS: What if you do ACCEPT: */*? If it’s absent, is is presumed?

TallTed: If you don’t specified, it is assumed.
… It’s a tool-specific choice.

pchampin: I need to think about a special header. It might mitigate the problem in the mean time.
… I think I understand how to make a PR that covers these ideas.

Attracting more implementation reports

pchampin: We’d like to have more implementation reports. Any idea how to encourage people to submit them?
… At the beginning of the work I created a small python script to test some implementations against semantics test suites? Is it appropriate for me to submit a response for someone else?

AndyS: You’d get into trouble. If you say it doesn’t pass, then you’re open.

<AndyS> RFC 2616: not in 7231: "If no Accept header field is present, then it is assumed that the client accepts all media types."

TallTed: It’s legitimate to run the test suite against any tool, but putting it in the report is a problem.

<TallTed> ( mentioning @ericprud [ in regards to text/turtle IANA reg, discussed above ] to trigger his eyes on this log when it goes into github )

james: There was a researcher at INRIA who made an effort to establish a mechanism for uniformly testing SPARQL endpoints.
… she didn’t have much success for a variety of reasons.
… You have authority, but if you want acceptance, you need support.
… If the tool has a community license, you can run it, but not say what the results were.

TallTed: It’s also legitimate to warn about licensing considerations.

gkellogg: How do we get people who have expressed support to actually report?

AndyS: It hasn’t been published long, and it may take some time.

TallTed: It’s also legitimat to run the test and submit the results to the implementor and ask “what’s up?”

pchampin: The polite thing is to give it back to then and ask them to submit something.

gkellogg: It’s never too late to submit an implementation report.

pchampin: I hope to have one for Rust soon.

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).


Succeeded: s/regrest:/regrets:/

Succeeded: s/star-turtle/star+turtle/

Succeeded: s/pchampin:/gkellogg:/