<chaals1> Meeting: RDF directional Literals

<addison_> https://w3c.github.io/rdf-dir-literal/draft-charter.html

<addison_> https://w3c.github.io/string-meta/#

What the problem is...

<chaals> [r12a show slides, where arabic rendering is broken]

<chaals> r12a: inline runs have the right direction, but the segments are ordered incorrectly

<chaals> … if we had said <textarea dir="auto" then it would have got the right base direction, and the segments would be ordered correctly.

<chaals> … but then it needs to have the algorithm applied everywhere

<chaals> MM: Unicode used to have a character to specify base direction?

<chaals> MD: Still does.

<chaals> RI: You can insert the unicode character at the start of the string. But that's hard.

<chaals> DB: Does copying pick it up?

<chaals> [sometimes… and sometimes not]

<chaals> [and you an't see it so you don't know if it is there, or where it is, and it goes wrong in many and wonderful ways]

<chaals> r12a: there are new isolating characters in unicode. But they don't work in deployment.

<chaals> Addison: it prevents spillover effects, but it doesn't solve the rest of the problems - like needing to have a direction anyway.

<chaals> chaals: and it's still a magic invisible character

<chaals> r12a: Ivan has a document that suggests various approaches that could ber used in RDF

<chaals> a document that looks at possible solutions

what happened...

<chaals> Ivan: there is no problem if you only use JSON, you can just figure it out for yourself.

<chaals> … JSON-LD cannot solve it, because JSON is only one serialisation of RDF and has to match RDF.

<chaals> danbri: In ancient times we decided to be careful and stick with the mistakes we made before

<chaals> Ivan: So, you don't have a way of labeling direction of a string.

<chaals> … so there was a discussion of how we could fix that.

<chaals> … so we described three solutions, one of which is the unicode character thing we have already explained as a bad idea.

<chaals> … One approach was to extend language tags, which was received with horror and hopefully convinced people not to do it.

<chaals> danbri: what if we made the language a space-separated microsyntax in the lang field.

<chaals> addison_: we did raise that idea. It would leak into the world beyond RDF. Maybe using a space would be a better version of that.

<chaals> ivan: We looked at RDF solutions. The obvious one was to go back and fix RDF by adding direction info and letting it cascade through the system.

<chaals> … another alternative was to define a new datatype for wellThoughtOutStrings that had the information they needed.

I think space would break turtle syntax: <> rdfs:label "Rob Sanderson"@en ltr .

Would misparse horribly

<chaals> …it wasn't nice, but worked.

<chaals> … and the latest one is a compoundLiteral. instead of special syntax, we replace the literal by a blank node with a value, language, direction, …

<chaals> … It was felt that fixing the core would be the best approach. We made a draft charter and put it out for feedback.

<chaals> … and pulling on a loose string in the core of RDF leads to a lot of cascading required work in a lot of places.

<chaals> … and in particular, you have to update a lot of implementations.

<chaals> … And the community said

<chaals> [crickets]

<chaals> Ivan: Andy Seabourne came back with Compound literal. So the RDF community is not aware of the problem apparently.

danbri: It's a lot of work to move the eiffel tower 2 centimeters

<chaals> danbri: it's not about hanging the specs, you need to talk to the people who are building sparql databases, and that is a lot of real work.

<chaals> gkellogg: Any solution requires doing something.

<chaals> ivan: the decision is that we cannot start up a working group to make the changes to the core spec.

<chaals> … so that's where we are. We still have the problem. What can we do?

<chaals> … the advantage of all the other solutions is they require no changes to the core implementations, and users could solve the problem, by moving to new terms or datatypes.

<chaals> … Which solution would we propose? How would we do it?

What to do

<chaals> IH: My personal preference is use the compound literal

<chaals> MM: Some of these products are databases, and how it is encoded in serialisation seems to be getting confused

<chaals> MM: The compound literal model can be functional, and we can produce a nicer serialisation syntax

<chaals> MD: there may be many schemas that already say "use a literal". so we would have to change a lot of actual people's behaviour.

<chaals> AP: derivative specs, that say "use a literal" - and none of those will pick this up. We see lots of specs and say "we want a literal to have direction"

<chaals> … this would let us fix the thing we are saying. But it doesn't fix the RDF space.

<chaals> RS: As soon as you are beyond the Literal, you haven't solved the problem. most strings will stay problematic.

<chaals> … whereas extending lang tags is horrible, but won't break stuff.

<chaals> IH: Or do it at the datatype level.

<chaals> RS: If you put space into turtle, it will get broken.

<chaals> DB: We had a workshop on property graphs. There is some sort of energy. There is RDF*, giving some wiggle room on the edges of a graph. My impression is that 3 or 4 RDF databases have been patched to handle this, whih suggests the community actually isn't dead.

<chaals> … It doesn't make it easier, but feels like there might be a larger conversation about taking a new look at RDF.

<chaals> IH: There may be someone who can pull off and RDF refresh. It ain't me babe.

<chaals> … it will take several years to get there and solve this. If that's OK, it might be a real answer.

<chaals> … The hole came around because Verifiable claims could not solve the problem.

<chaals> … If we can wait a few years, we can deal with it.

<scribe> scribenick: azaroth

chaals: I don't think there's an easy way to move the stack, it takes a long time
... the problem with datatypes is that instead of having to change a dozen or two engines, you need to take 100s of millions of people that you can't find
... there's no shortcut
... if it takes a few years, then it has taken 20 years to NOT have a solution at all
... 23 years and then a solution, that seems pretty reasonable to me
... this is a big piece of work, it feels like a small problem, but it keeps growing
... we grow more technical debt the entire time
... if you think we can do it in a few years, that seems a sensible approach

ivan: I don't have the feeling ...

danbri: I'll throw schema.org into the mix
... i'm responsible for it as a multiple stakeholder project that's also my job
... use microdata as rdfesque
... lots of json-ld and a ton of microdata
... relatively easy for schema to say we're loosely coupled to rdf, generalized graph with literals here and blank nodes there
... can use schema to nudge things in the right direction. At google we could do a better job of languages generally
... lots of it out there ... 1 in 3 or 4 pages depending how you count

addison_: If we knew the solution, we could push the implementations

danbri: looking to sit on the fence a little

bigbluehat: there is will to address this and more
... RDF*, there are databases being eaten by property graphs, but a willingness to push
... this charter went to a room full of people not doing RDF
... so the opportunity is that if we can bring the people in that care, or use RDF CG, to herd the cats into the room
... is there momentum to get people towards this. Could be stand alone, could be 3 years bigger thing
... opportunity to see it in advance with schema.org
... json-ld has uncorked the bottle, and a lot of specs depend on it
... json-ld then depends on rdf ... the other course is for json-ld to get off the RDF dependency

addison_: If we can get the destination right, there's other models for spec development
... work through the technical choices. We have so many specs that depend on json-ld that are coming down the pike
... we need to do /something/
... alternative is that we have the same thing happening in today's space as previously ... no one went out of business, but we'd be locking the solution outside of the spec
... so it would be non-interoperable and we want to avoid that
... should know the direction and some agreement about how to get there. If we can fix RDF at the same time great

gkellogg: if there was magic pixie dust, and JSON-LD does it right, then all the rest of the specs work
... if there's a migration path with syntactic sugar for a json-ld value object to have it create the compound objects (or whatever) to create a bridge towards a deeper solution down the line
... it's not a perfect solution, for the applications on top of it
... could probably shoehorn into the json-ld 11 work
... once it's out there, then it's out there
... but in a later version we can rebase it against a rdf 2.0 or whatever

ivan: Benjamin, one thing is that the call went to the SW mailing list. the rdf folks were in the loop, not just AC
... went to a bunch of lists for semweb and i18n. If Berlin effect is so strong, I don't know
... what this tells me and it goes the same way as what dan said, it looked like a small problem but it opens pandora's box
... better to wait to see if a full WG comes into being
... there's a number of problems that have been described
... this would be one minor item amongst many others
... so wait and hope
... if we do something in json-ld today, e.g. 2.1.4.2.2, that can't be represented in rdf, then we would lose it
... but could define in RDF the compound object, with all its downsides for turtle and owl and so on
... if I work in the owl space, then I won't be able to use it
... but in JSON-LD, the syntactic version is obvious for the current json-ld structure
... if I don't care about the RDF, then it's good

addison_: Need to take an action

chaals: Suggest we take this to JSON-LD, then everything downstream works unless it's full RDF stack
... second, if we just do it in JSON-LD and then go back to RDF and backfilled to make it work?

ivan: in json-ld spec, we have to define the rdf we generate
... so must define some sort of rdf term in some namespace, which is not in the charter ...

gkellogg: rdf:JSON

chaals: it's not pretty, regardless of how we do it

bigbluehat: Please come to the WG to discuss

<addison> summary of hallway: I18N agreed to come to JSON-LD tomorrow 1400 to discuss implementing a super-set fix in LD 1.1

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: chaals, addison_, RobSanderson, MartinDuerst, AddisonPhilipps, IvanHerman, r12a, Rob_Sanderson, bigbluehat, danbri, gkellogg
Present: chaals addison_ RobSanderson MartinDuerst AddisonPhilipps IvanHerman r12a Rob_Sanderson bigbluehat danbri gkellogg chaals1 ivan Mohd_Saleem duerst
Found ScribeNick: azaroth
Inferring Scribes: azaroth

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)