Re: Schema.org, Enumerations and Wikidata proposal

Yes, exactly what Denny says

Guha

On Apr 13, 2017 2:57 PM, "Denny Vrandečić" <vrandecic@google.com> wrote:

> Once we know what we want, I think the next step is to initiate a
> conversation with the Wikidata community to make sure they like it too. I
> am happy to initiate that once we have agreement here.
>
> I agree with Martin Hepp that we should be mindful of the exact approach -
> I don't think we are planning a whole snapshot of Wikidata. My currently
> favorited solution is basically a materialized SPARQL query with the
> results stored on lists.schema.org, and rerun on release, but at the same
> time always allowing the Q-Identifier as well (since these should remain
> stable, as Martin's work indicates).
>
>
> On Wed, Apr 12, 2017 at 7:17 AM R.V.Guha <guha@guha.com> wrote:
>
>> Denny,
>>
>>   Dan brings up a good point. We should make sure Wikidata is ok with
>> this. How do we go about finding out?
>>
>> guha
>>
>> On Tue, Apr 11, 2017 at 10:10 AM, Dan Brickley <danbri@google.com> wrote:
>>
>> On 11 April 2017 at 19:00, R.V.Guha <guha@guha.com> wrote:
>> >
>> > On Tue, Apr 11, 2017 at 9:42 AM, Dan Brickley <danbri@google.com>
>> wrote:
>> >>
>> >> Someone is also bound to mention versioning and whether Wikidata's
>> >> type and property names are volatile and whether we should use Q12345
>> >> IDs instead; I suggest we defer that conversation for now.
>> >>
>> >
>> > Which is kind of why it would be better to periodically copy over. The
>> > stability expectations of wikidata vs schema.org are different.
>>
>> Perhaps, although we had a similar trajectory to more clearly
>> identified snapshots/releases. They might find value in doing this
>> too. Or outsourcing that role to schema.org. Worth sync'ing with them
>> before writing too much code, at least - there may be variations on
>> the idea that will make this effort more useful in the Wikidata
>> ecosystem.
>>
>> Dan
>>
>>
>>