RDF-star WG biweekly focused meeting

Which parties carry what costs of text/turtle changes, and do those outweigh which benefits for whom? 1

ora: Something from Ruben Verborgh. Any thoughts?

pfps: This is not limited to Turtle, RDF/XML, NTriples... all of our surface syntax are exactly in the same situation

rubensworks: also the SPARQL results syntaxes

ora: We need to things, eventually a solution and before that a response to Ruben

rubensworks: Based on some scrawling, several solutions have been proposed

rubensworks: the simplest one, do nothing and carry on with the changes

rubensworks: Second solution, introduce new media type but it comes with some cost, adoption, web browser restrict accept header length

rubensworks: An other is to make use of profiles

rubensworks: An other and it's the one I am personnaly in favor of is to keep the media type but introduce some in syntax version mechanism just like JSON-LD and HTML

rubensworks: the motivation is that currently text/turtle means Turtle 1.1 and if we change that, the contract break

gtw: All line based formats will have a hard time for in format versionning but it sounds a good approach for eg Turtle

gtw: if not, we open ourselves to get new media type each time a WG update the spec

AndyS: My personal concern is that to fix a problem we pay occasionally, we split the world in two

AndyS: If there is an inline version thing, then there is a choice, is it mandatory or optional to use RDF 1.2 features?

pchampin: I like the idea of optional inline version with the statement "you should add a version if you use RDF 1.2 features such that clients can break gracefully"

pchampin: Line formats makes versionning harder but error recovery much easier, you can just restart on the next line

james: With content negotiation, I have expected that the server can answer with whatever it wants

AndyS: A syntax error is not a new class of error a web system would have to deal with anyway

ora: I am not sure a HTML-like recovery system would be a good thing for RDF

ora: If there is something the client does not understand, the client should know it does not understand

<pchampin> well, RDF is monotonic, so a subset of the triples would at least not contradict the whole graph

ora: we need a decision on the principles, even if we don't deal with the details of the decision yet

<fsasaki> just to add me comment to the minutes: having the HTML / CSS / JavaScript way of "doing nothing" may have some benefits, going the path of loose coupling a bit more than done so far for RDF

ora: How this inline mechanism work in Turtle?

<niklasl> (My notes that I pseudo-read-from): I'm +1 to keep media type. Excellent points by all. I think focus is best spent on considering viability/workability of a version parameter; and also pro/con of in-band (version keyword in "prelude") (break early; mandatory or not)? With considerations on what is deployed out there, and when clients/servers are

<niklasl> likely to upgrade to 1.2 (as in make use of the new features; cf. unstarring). Error recovery is also very interesting (I think CSS is particularly interesting in that respect).

james: My point is not only that the server can return the content-type it wants but it can also provide the adequate signal for the client to understand why it might fail

pchampin: The inline mechanism should be a SHOULD because there are situation where it is hard for publisher to know if they are going to make sure of specific features like triple terms

pchampin: and so to mak sure that in the happy case (no triple term) the old implementation still work

<Zakim> AndyS, you wanted to ask about general toolkit (e.g Spring) support for "version="

<tl> +1 to an optional (SHOULD) @version parameter, since it allows to break early and with explanation

AndyS: I don't know the state of the world is out there, if you send a `version=` parameter on a media type, would framework like Spring fail or handle it properly?

pchampin: the version parameter of requests should be optional

pchampin: I will update my FOAF profile to serve the response with `version=1` and send a message to the semweb mailing list to see if implementations choke on it

ora: Would it make sense to enumerate what the difference approaches mean for the different syntaxes?

<niklasl> Yes; one or both of 1) version keyword and 2) version parameter on existing media types?

rubensworks: I am not sure if it make sense to enumerate all approaches even if it seems that the inline version in addition to the version= media type parameter seems to get traction

ora: I am wondering should we somehow clearly spell what the failure modes are and possible courses of actions

Triple terms in subject position - issues with RDF/XML? 2

tl: We had a discussion at the semantic task force, I find it dangerous to forbid triple term in subject positions

tl: RDF is very liberal, the parallel to literals is very flawed

tl: I am afraid we are narrowing too much on provenance annotations

<tl> w3c/rdf-concepts#138 (comment)

<gb> Issue 138 Triple Terms in Subject Position (by rat10) [ms:CR] [spec:substantive]

tl: to discuss the statement itself triples terms in subject position should be allowed

<pfps> it is "theoretically possible" to do lots of things, so no warning about it is needed

tl: we should not only focus on occurences and miss types completely

niklasl: for me it's clear for quoted triples are abstract things, I just disagree to a lot of conclusion, see the discussions

<niklasl> Add as little as is needed. (See also https://en.wikipedia.org/wiki/Rule_of_least_power .)

james: I don't believe the comitee understand things well enough to enforce restrictions. I would not exclude symmetry.

<niklasl> Symmetry is already excluded (literals). See also "symmetric RDF" in https://www.w3.org/TR/rdf12-concepts/#section-generalized-rdf

<ora> STRAWPOLL: Allow triple terms in subject position

ora: I would like to take a strawpool on how people feel about this

<niklasl> -1

<tl> +1

<doerthe> +1

<rubensworks> +0

<ora> -0.7

<james> +1

<AndyS> -1

<eBremer> +0

<gtw> -0.5

<olaf> +0

<AZ> +1

<fsasaki> -1

<pchampin> -0.5

<Tpt> -0.7

<enrico> +0

<TallTed> -0.1

<Dominik_T> 0

<pfps> -epsilon There is no technical harm, but I forsee the seminal example rising its ugly head again.

ora: There is no concensus, how do we resolve this?

<AZ> There was already a strawpoll about this on January 30th.

<niklasl> What is possible to undo if the wrong choice is made?

ora: Symmetry may not be the final convincing argument, RDF is not symmetric with literals

<TallTed> AZ -- It's natural for straw poll results for the same question to change over time, even short term. They're entirely non-binding, and just to get a sense of people's feeling at the moment they're run.

pchampin: My personnal preference is to allow them in subject position just like literal. I voted -0.5 because I heard some implementers are scared about it and we made the decision to disencourage the usual of triple terms outside of the object of rdf:reifies

<niklasl> Also +1 to pfps; that (seminal examples cropping up all over; users asking about what to do) is more concretely my concern.

pchampin: If we allow triple terms in subject position, we should reconsider the "SHOULD be used as object of rdf:reifies" in concepts

<doerthe> but discouraging is not the same as not allowing

james: What is that so hard to have triple terms in subject positions?

<doerthe> I think the "discouraging" was already the compromise

<Zakim> ora, you wanted to ask if this could be handled with some kind of conformance definition

<niklasl> If literals had been allowed as subjects, I am far from convinced users would have picked up that data like `"Eureka" :saidBy "Archimedes"; :inLanguage "el" .` is a Bad IdeaTM.

pchampin: an option might be to allow triple terms in subject position only in generalized/symmetric RDF

<niklasl> tl, you're looking for owl:sameAs

<doerthe> OK, niklasl, but in your example it does harm because that is something many people will do with EXACTLY that string

<niklasl> doerthe, I know, I do understand the risk-level difference (who "owns" the combo of all three constituents).

<tl> @niklasl that's a possible workaround, but I'd like this issue to be addressed in RDF proper

pchampin: My implementation internal data structures support generalized RDF. The parsers are complient and there is an additional "generalized TriG" syntax and for serializing there is a flag to prevent it to serialize things outside of standard RDF

<niklasl> When in doubt, only add what is *needed*.

ora: I would like to understand what the road for concensus would be

<tl> @niklasl is prohibiting needed?

fsasaki: what about classifying the vote with "can live with" and "cannot live with"

<pchampin> +1 to have 2 polls: "I can live with TT in subject position", "I can live with TT forbidden in subject position"

<pchampin> if one of them has no objection, then we have at least a weak consensus

<niklasl> @tl, define prohibit. We prohibit triples to be three-tuples as opposed to n-tuples?

<pchampin> if both get objections, we need to record dissent and move forward

ora: no extra point?

<tl> niklasl half-full vs half-empty gasses etc