Re: Schema.org, Enumerations and Wikidata proposal

On Apr 13, 2017 23:57, "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).


That is more or less the approach I took with properties last year, except
the only artifact I generated from the SPARQL results was a json-ld context
file.

A related integration to consider is other [what we have recently called]
external extensions such as GS1's vocab, see http://gs1.org/voc/

As with Wikidata they manage, release, update this externally to schema.org's
process, and yet there is interest in having their vocab discovered from
our schema.org site and in encoraging instance data to use their vocabulary
where possible. So we should consider where/how within schema.org we would
expect GS1's "cheeseFirmness" property, or their various types, to show up,
just as we are asking for Wikidata. Also note that term naming clashes are
possible between these repositories, if unlikely.

Dan



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
>
>
>