Meeting minutes
approve minutes
<ora> https://
ora: propose to accept minutes
<AZ> +1
<enrico> +1
<Dominik_T> +1
<olaf> +1
minutes accepted
status updates
az: can we talk about levels of conformance?
gkellogg: discussion on text direction
… some activity from the I18N folks
… proposing to extend abstract syntax to include text direction as a component of literals
… this was an issue in JSON-LD
… we now have the opportunity to update this in a more fundamental way
pfps: I argue that RDF language text strings do not need text direction. It does not change the meaning of the string at all.
… It's only necessary for presentation.
… I'd argue against I18N group if they push back.
… RTL and LTR would compare as different things.
gkellogg: not enough experience present - suggest a special meeting
ora: Yes, agreed, that's a prudent way to go.
… The whole thing with text direction is sort of "black magic".
… I've faced this before and welcome more expertise.
AndyS: I have a friend that speaks arabic, and he though it might be tough to accomplish.
… The way it interacts with URLs is.
… It's complicated when there are bits of text floating around.
<AndyS> s/aribic/arabic/
pfps: I'd like to get it done early. It will change every document and piece of software.
… It's a fundamental change to RDF; potentially just as fundamental as embedded triples.
ora: whether it's a change or not, it would be good to understand it.
ACTION: chairs to contact I18N group to start discussion.
<ghurlbot> Cannot create action. Validation failed. (Invalid user for this repository?)
Use Cases
pfps: I sent out an invite to join the task force. There are a number of people on the group.
… I sent out some messages on a proposed policy and some example use cases, without feedback.
… Either make comments, or produce your own.
… I'll put that in the issue.
AndyS: Were the ones from the CG be carried over?
pfps: I will take it upon myself to have someone reach out the the proposers to create real issues for the WG.
AndyS: I'm worried it's putting barriers in the way.
pfps: It needs to be more than a couple of sentences. A WG member could pick it up and continue the work.
… I'll make sure that every existing UC has an entry.
SPARQL docs
AndyS: Does are passing checks, except for entailment, which requires an editor.
pfps: I volunteer!
… I looked at it a while ago and expect it won't need much change.
Conformance
<olaf> pfps, find the use cases doc from the CG at https://
AZ: I proposed two options: one to say we have only one standard RDF 1.2, but define a weaker conformance that only requires we conform to slight updates to RDF accounting for errata and so forth, but exclude embedded triples.
… That might be "weak" or "classic" conformance.
… Full conformance would take embedded triples into account.
… The other option is to say there are two versions of RDF, one with embedded triples, and the other without.
… Maybe "RDF-no-star" and "RDF". No weak or full, you just implement one or the other.
… Like various OWL profiles, you implement a different specification.
… We can conform to one or the other.
<Zakim> pfps, you wanted to say that the non-embedded conformance should be called RDF 1.1
AZ: Or there's only standard, but two ways to conform.
… I'd say if we have a profile plus full RDF 1.2, we have two specifications.
… There are risks, but having a clearly identified profile would make it more clear what the conformance is.
pfps: I'd suggest "weak" should be called RDF 1.1 or RDF 1.1.1.
AZ: there are names for two types of conformances, and names for different profiles.
… I'd say that "weak" is a way of partially conforming, and RDF-no-star would be it's own thing.
pfps: If it's a profile than something that abides by it needs to be able to deal with embedded triples.
AZ: when I say profile, I don't mean exactly the same thing as OWL. I'm using it in a more informal way.
… A sub-language of RDF 1.2 which does not include embedded triples.
ora: Wouldn't RDF 1.1 conformance be something we already have.
… If we make the other non-star changes to the spec, it would be a possibility.
… Secondly, how has the OWL profile mechanism worked in practice?
AZ: I'm not sure about all the details about OWL 2 profiles.
… The profiles mostly restrict reasoning.
pfps: A number of OWL processors accept ontologies as RDF documents and complain if there's something they can't handle.
… There are other processors which look at it and determine what profile it fits in, and then use that using an appropriate reasoner.
pfps: In some cases, there is something out side of the system that determines if it's okay.
Souri: In Oracle, we allow the user to specify what profile to use (-RL or -EL).
ora: I think the situation with OWL profiles is different, as there is no syntactic difference.
… In RDF-star, processors will see input they can't handle.
pfps: There is and is not difference in OWL profiles when it comes to the native syntax.
… What happens is before the ontology is set to the reasoner there is a step to be sure the ontology fits.
AndyS: Is there going to be one profile that _is_ RDF 1.2, and others that are subsets?
… If we have two with equal weight, there's a bifurcation. We should make 1.2 _the_ output.
… The charter is no changes that change RDF 1.1 entailments.
… No changes such that an RDF 1.1 processors would make different directions.
… Text Direction would make such a change. If we're touching quite a lot of bits and pieces, we can end up trying to parse the charter to see if we conform.
… Every WG that has had a charter to not change something ultimately needs to make a judgement.
… Sometimes things come up which are obvious improvements.
ora: We have several things that are important. Backwards compatibility and bifurcation.
… Ideally, I'd like to see a new spec that everything must conform to, but that may be to idealistic.
… Some might choose one set of new features over another.
… We already have RDF 1.1 conformance. If we make small changes outside embedded triples, it should be included in "weak/classic" conformance.
… If we add things that substantially change things.
AndyS: If you introduce a datatype that introduce things that processors are supposed to interpret, you've fundamentally changed things.
… Considering SKOS labels, if you introduce something that gets too naively passed through 1.1, things can get lost.
… We're also set up for a living specification that does allow new features to be introduced.
ora: What's the way forward?
… there's obviously embedded triples or no embedded triples.
… I'm not sure what happens if we say there are a lot of new features and you can pick and choose.
AndyS: The RDF 1.1 WG did make a big change by getting away with strings having no datatype.
… It went smoothly.
… Within the SPARQL WG, it was an issue.
… It gets in the way if you're too dogmatic about "no changes".
… Data is different though, as it stays around much longer.
ora: Next step is to write an actual proposal. The conversation is useful, but a bit abstract.
… I'm seeing there's old, new, and embedded triples.
next steps
<pfps> +1 to defer - this discussion needs some time
ora: I wanted to discuss Enrico's work, but think we should defer to next week.
enrico: There's a good discussion on the mailing list.
+1 to a meeting specifically on Enrico's input
ora: In conformance, let's work on writing down something concrete.
ACTION: AZ to work on conformance proposal.
<ghurlbot> Cannot create action. Validation failed. (Invalid user for this repository?)
ACTION: Antoine-Zimmermann to work on conformance proposal
<ghurlbot> Created action #23
ora: Enrico will prepare an introduction for next week.
ora: adjorned