Meeting minutes
Announcements and newcomers
pchampin: Not too much feedback from the tweets and anouncements of the updated draft.
Open actions
<pchampin> https://
pchampin: No open actions at the moment
gkellogg: I had an action to reorganize the concrete syntaxes, which is done.
Open PR #149 - splitting manifets
andys: not really technical, just organizational
Old or new media-types for RDF-star
pchampin: I want to discuss the media-type issue.
<pchampin> https://
<pchampin> https://
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?
<gkellogg> +1
<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://
<TallTed> and he has failed to update that doc from pointing to https://
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
<gkellogg> +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?
gkellogg: there is no good solution, we need to caution people on the use of these format in production systems
… while the profile parameter is not normatively ok, it could be a good option
… 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.