Meeting minutes
Unstar algorithm and upcoming the RDF Concept CR 1
ora: would prefer to wait for pchampin for this.
Expected behavior of systems when profile does not match used features 2
gkellogg: There are a number of ways to specify a version you want.
… one of them are HTTP accept headers.
… We should talk about how implementations are expected to behave.
… We need to say something about this, even if we cannot mandate it.
ora: Is this an error? we can write conformance tests. But, what is the expected behavior of consumers?
ora: For reading, the question is how is the system behaving for consuming.
… gkellogg you also say we have a potential solution for the text direction downgrade?
gkellogg: yes, there is a proposed solution from JSON-LD.
… The system is recommended for years by the i18n WG
ora: could we simply refer to an appropriate JSON-LD document, or what do we need?
… gkellogg you are suggesting an informative part.
gkellogg: yes we could do that.
ora: the minimum for an informative description would be to refer to JSON-LD for use of the i18n namespace for language/text direction.
AndyS: If we use the version as a declaration of intent, we should realize that we're also creating a system for the future. A future version of Turtle could have syntax and/or semantic changes.
… The other interesting use is that we now have a way of making a declaration of the expectations for the data.
… I don't think we can mandate the unstar algorithm, which would require that it be normative.
… If we keep things on the level of advice, we're in the same situation we are today.
… Unstar would be something that could be used be a publisher.
<niklasl> +1 for advisory & informative (and for the points re. conneg)
AndyS: ACCEPT requests are advisory, and we should not do more.
ora: we shouldn't mandate specific behavior.
… What about failing, rather than returning something wrong.
AndyS: It can depend on usage of if it should generate an error; large documents could require a lot of work before you knew it was using inappropriate features.
niklasl: If you concatenate multiple files and one contains an explicit version that is lower than others, it would be confusing.
… generally, if you use VERSION 1.2, you should be able to take anything, but if you add 1.1, it would be inconsistent.
james: What would one expect if you're not able to satisfy the request.
… Would it be fair for the recommendation to require that systems announce the version they're sending back.
ora: There are multiple things to figure out.
… Can we use as guidance things that already exist? for example, what implementations do when there's a syntactic error.
AndyS: On the web, the responsibility is with the receiver. You have to be defensive if you care.
ora: consuming RDF isn't always a transaction.
ktk: Are we talking just about content negotiation, or something more.
… In content negotiation, you can say 406 "Not Acceptable". We don't need to redefine content negotiation.
AndyS: We can put the advice about using unstar in the unstar document, so that it claims it can be used to satisfy such requests.
ktk: I implemented content negotiation for RDF, and I realized that many implementations handle such headers differently, so it's not trivial.
AndyS: The amount of stuff that is returned text/plain no mater what you ask for is crazy.
… People just put files up on web servers, and they don't have any further knowledge about media types.
… Not so much a problem for results.
ora: As spec writers, we need to minimally offer advice for producers and consumers.
… Also, we need to decide where does it go.
gkellogg: We don't have a "best practices" document.
ora: What else could go in such a document? Can we collect all the ideas to put into a single document.
AndyS: The IRI advice note in concepts could go into that document.
ktk: Would it be wrong to go in the Primer? It's mostly for consumers, but could goo there as well.
niklasl: The Primer is smaller than Concepts, but it might take on more.
… Uses of fragment identifiers might go in there, and more advice on RDF documents and syntaxes.
… But, it could be a best practices that is distinct from the primer.
ora: At one extreme, we could leave them in existing documents, at the other, create new documents.
… This could be rather large, so it may make sense to move in a separate document
AndyS: A proposal might be to put an info note in Concepts now, and see how much it grows.
… We can then review how things are looking closer to CR.
gkellogg: different groups have a primer and a best practices, JSON-LD for example.
… They serve different audiences.
<niklasl> I agree. The primer "is designed to provide the reader with the basic knowledge required to effectively use RDF". (From its Abstract.)
gkellogg: It's also a place to point to other best practices documents, like i18n.
ora: First thing to do is to produce the content and put it in some document, then we can decide how to move anything around.
gkellogg: I can write down some things we agree on.
<niklasl> +1 for Postel's law
ora: might be a good idea to reinforce Postel's Law in our documents.
… We need some text to look at that we can decide on.
<james> an operator, such as fetch in node, is very lenient. it just passes incompatible content through _ with the actualy content type_ and leaves it to the application to handle the consequences.
gkellogg: I can do a PR that we can use for discussion.
ora: sounds good.
What advice to put in RDF specs about the handling of version labels. 3
gkellogg: This is part of the previous issue.
Acknowledge the two purposes of this document 4
Dominik_T: I agree with pchampin on this discussion. We should clearly describe the main purposes of the document.
… No matter what we decide on the name or scope, it is a big change in structure and content.
… The changes are major and will need careful planning, and can't loose important content.
… I'm willing to start a PR, but not sure how to do this properly. Smaller PRs are hard, but one bit PR may make it hard to follow.
ora: Can we have a plan in advance so we know?
… With a plan, we could have separate PRs and annotate the plan to point to those PRs.
Dominik_T: I can start creating such a plan in GH.
… I think it will be hard; we need to puzzle the structure, and that make it hard to decide how to structure.
<pfps> RDF 1.1 Schema already includes sections that are not about the rdfs namespace, so I don't view this as a change to the document, just an ack that it covers more than the rdfs namespace.
ora: Then there's the potential renaming of the document.
… If I understand pfps's comment, we would explain the document in the introduction/abstract
AndyS: A suggestion about datatypes in the rdf: namespace, what do people think about moving the three datatypes from concepts here.
<niklasl> Sounds good to me.
<pfps> Yes, in my view all that is required is to change the abstract and the introduction, and probably not by very much.
AndyS: rdf:JSON, rdf:HTML, etc are defined in Concepts, but might go to Schema.
gkellogg: we have inbound links to those datatypes in concepts.
ora: Even if we put most of the content in schema, they don't need to go away entirely.
<pfps> rdf:HTML and rdf:XMLLiteral were already in RDF 1.1 Schema, so there is precedent.
ora: Do we need a decision on renaming the document?
<ora> STRAWPOLL: Rename RDF Schema to RDF Vocabularies?
gkellogg: Without some specific support, I'd say leave it as is.
<ora> -1
<william-vw> +1
<Souri> -1
<james> -1
<gkellogg> -0.5
<Dominik_T> -1
<enrico> -0.9
<ktk> 0
<pfps> -0.5
<AndyS> 0
<eBremer> +0
<niklasl> +0.25
<gtw> +0
<TallTed> -0.9
william-vw: I don't see an issue with renaming it to "RDF Vocabularies", but I don't think it would be confusing if there's a note about renaming.
… URL changes are solvable.
gkellogg: W3C has infrastructure for redirecting shortnames.
niklasl: I'm not sure it would have a big impact to change it, particularly over time. It would have been nice if it had been Vocabulary all along.
… Then there's the "Vocabulary" vs "Ontology" discussion.
ora: "Schema" is greek, we'd be forced to use "Schemata" for the plural.
… I suggest we defer this until the end, but we have other things to do.
… I think a plan for what to do will emerge as we work further.
Different parsing of the same absolute IRI with or without base IRI 5
AndyS: An additional factor is that RFC 3986 says that dot segments are only intended at the beginning of a path.
… And, the resolution algorithm has a "strict" and "lax" description.
… Even just coming from 3976 there are options for us to consider.
ora: What happens if we don't do anything?
… I'd like to avoid breaking existing RDF systems. On the other hand, there's going to be trouble either way.
AndyS: It's only when you have dots within a IRI that has a scheme.
… In the advice note, we should mention something about dots, whatever we do. Jena can do either, and no one has ever really noticed.
niklasl: Thinking about URIs coming up with diffs and the like, that uses multiple dots. If an IRI looks like it's resolved, I wouldn't touch it.
… We're ambiguous now, and it's not clear if a "resolved" IRI must still be rsolved.
AndyS: In the IRIs note, we have a section intended for something else about minting IRIs. We suggest to normalize by eliminating "/." and "/..".
<AndyS> rdf-concepts: -- """Normalize IRIs to remove "/./" and "/../" in the path component of an IRI."""
ora: Can we put in something to normalize that to be consistent.
Tpt: I'm not sure we need to be consistent, as we say you should not use problematic IRIs
… When there are dots in IRIs that are already absolute, systems should not resolve them.
<niklasl> +1 kind of a "if you do, we assume you might have your reasons"
ktk: Do we agree that engines should all behave the same way.
gkellogg: do Turtle parsers always resolve?
niklasl: Can we assess what data in the wild would change?
<AndyS> Example -- <http:abc> base <http://
niklasl: Implementations behave differently, and we don't know what the data says.
AndyS: An example that doesn't use dots or slashes.
ora: I'll send regrets for next week, at Semantic Arts event.
ktk: Me too :)
ktk: We'll send an email with an agenda or a cancelation by next wednesday.