The proposal currently doesn’t mention data nodes (e. g. wdata:Q2). I don’t think there’s too much to discuss (we shouldn’t need any special triples beyond the standard schema:version, schema:dateModified, a schema:Dataset, and schema:about wd:Q2 that we already have for items), but I do have one question: should we have data nodes for sub-entities (forms and senses) as well, or only for lexemes?
Topic on Extension talk:WikibaseLexeme/RDF mapping
Yes, I omitted them because imho they should be the same as items/properties and not depend on the entity type. The wdata:... nodes are about the "storage unit" (a.k.a. wikipages) that contains the data and could have a revision timestamp... So, I believe it make sense to have only them for lexemes and not forms and senses that belongs to the same "storage unit" as their lexeme. It will also stay consistent with the current behaviour of outputting there some page properties. If you are ok with it I could add a section about it in the proposal.
I agree that it makes more sense to only have data nodes for the lexemes, but I think it would be nice to mention this somewhere in the proposal.
I agree that Forms and Senses don't need to have separate data nodes, but I think they should be connected to the Lexeme's data node via schema:about.
Yes, it's indeed useful. But it adds a lot of triples for what I believe is a use case that could be easily covered by a property path (schema:about/(ontolex:lexicalForm|ontolex:sense)?). @Smalyshev (WMF) what do you think about it?
In WDQS, wdata: node is compressed into wd:, so I don't think having extra schema:about has too much sense for querying - you could easily get from Form/Sense to Lexeme node, which will have the schema:about. Long story short, I think the scheme is good as it is now.