This model is not good.
If you dump *all* such matches from whatever source into a single
property, then you force people to use string-comparison filters if it
is a particular source (eg schema.org) that they are interested in.
That may not be such a problem if you're only interested in incoming
matches (eg matches *from* schema.org), but if you're going to want
outgoing matches (matches *to* schema.org), it's tiresome and horribly
inefficient.
Far better to have a dedicated external-id property for schema.org,
which would avoid this; and if there are important concepts there that
we don't have an item for on Wikidata, then create those items.
-- James.
On 26/09/2018 06:57, Andra Waagmeester wrote:
I would certainly support this proposal or can even propose it. Would it
also be an idea to do the narrow equivalent, at the same time? Any
objection to naming them broad and narrow match, to reflect the mapping
relations in SKOS?
On Wed, Sep 26, 2018 at 3:54 AM Thad Guidry <thadgui...@gmail.com> wrote:
Sure, Dan
aggregate demand <https://www.wikidata.org/wiki/Q1801078> -- broader
external class --> https://schema.org/Demand
place of devotion <https://www.wikidata.org/wiki/Property:P5873> --
broader external class --> https://schema.org/Place
festival <https://www.wikidata.org/wiki/Q132241> -- broader external
class --> https://schema.org/Event
Usually we can discover these relationships quite easily with "What links
here" on the GUI and applicable SPARQL queries, but then would like to
apply the Wikidata->Schema.org mappings when we discover those
relationships can be made. I suck at PHP, so I couldn't build or
contribute to a native application for Wikidata to host that application to
auto discover some of these mappings, but would be happy to assist someone
who could code in PHP to build such application...here's looking at you,
Magnus ? :-)
-Thad
+ThadGuidry <https://plus.google.com/+ThadGuidry>
On Tue, Sep 25, 2018 at 7:07 PM Dan Brickley <dan...@google.com> wrote:
On Tue, 25 Sep 2018 at 16:35, Thad Guidry <thadgui...@gmail.com> wrote:
Hi Team !
+Dan Brickley <dan...@google.com> +Lydia Pintscher
<lydia.pintsc...@wikimedia.de>
Schema.org mapping is progressing on every new Weekly Summary "Newest
properties" listing.
That's great ! And thanks to Léa and team for providing the new
properties listing !
What's not great, is many times, we cannot apply a "broader external
class" to map to a Schema.org Type. This is because "broader concept"
https://www.wikidata.org/wiki/Property:P4900 is constrained to
"qualifiers only and not for use on statements".
We are able to use the existing "narrower external class"
<https://www.wikidata.org/wiki/Property:P3950> , for example like here
on this topic, https://www.wikidata.org/wiki/Q7406919 , but there is no
"broader external class" property in Wikidata yet from what we see.
It would be *awesome* if someone could advocate for that new property
to help map Wikidata to external vocabularies that have broader concepts
quite often, such as Schema.org.
Could you give 2-3 specific examples, to help motivate the request, for
folk who're not tracking this work?
Dan
-Thad
+ThadGuidry <https://plus.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
---
This email has been checked for viruses by AVG.
https://www.avg.com
_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
