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 <thadgui...@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
>
_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply via email to