No, sorry, that is not what I meant. When I said "current data model" I meant the "currently proposed data model". Sorry for being sloppy.
So it assumes new entity types for Lexemes, which are not just special forms of Items. And it is not reliant on an underlying graph model.
Daniel already sketched out how 'product' may look like. Since the current implementation does not support Lexemes, I can not just put it on Labs.
But there could be a Lexeme "produc-" which is pointed to from Daniel's Lexemes for "to produce", "production", "producer", etc., which could point to "produc-" via a statement, say, "root word" or similar. In the end, it really is unclear whether that is correct or not, but it sure is a possibility that can represented with the currently proposed data model. Which properties exist, how they are linked to each other, etc., is all up to the collaborative decisions which the community has to make.
On Mon, Sep 19, 2016 at 12:38 PM Thad Guidry thadguidry@gmail.com wrote:
Denny,
Ah. very cool. So its currently supported just by the flexible nature of Wikidata's backing triplestore, Blazegraph and its generic graph structure, I assume what you mean.
So just having statements perform the linking to Lexemes that are just Q items themselves, but with a special statement that says... 'I am not an entity, but instead a Lexeme".
Can you or Daniel start with those few lexemes for 'Product' as Daniel and I mentioned , perhaps in Labs or somewhere, so that all of us can begin to see how this might work using statements ?
Thad +ThadGuidry https://www.google.com/+ThadGuidry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata