Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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.
-Thad +ThadGuidry https://plus.google.com/+ThadGuidry
On Tue, 25 Sep 2018 at 16:35, Thad Guidry thadguidry@gmail.com wrote:
Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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
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 danbri@google.com wrote:
On Tue, 25 Sep 2018 at 16:35, Thad Guidry thadguidry@gmail.com wrote:
Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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
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 thadguidry@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 danbri@google.com wrote:
On Tue, 25 Sep 2018 at 16:35, Thad Guidry thadguidry@gmail.com wrote:
Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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
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 thadguidry@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 danbri@google.com wrote:
On Tue, 25 Sep 2018 at 16:35, Thad Guidry thadguidry@gmail.com wrote:
Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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
On 26/09/2018 08:46, James Heald wrote:
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.
And just to add:
A dedicated external-id property then also means you can use qualifier P4900 "broader concept" as intended, as a way to represent and query within wikidata the structure of the external hierarchy.
-- 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 thadguidry@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 danbri@google.com wrote:
On Tue, 25 Sep 2018 at 16:35, Thad Guidry thadguidry@gmail.com wrote:
Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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
On Wed, Sep 26, 2018 at 9:47 AM James Heald jpm.heald@gmail.com wrote:
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.
Creating a dedicated property for schema.org, would also imply the need for creating designated properties for other context providers such as OBO, SIO, etc. I see that having to filter on matching uri providers in a single property can be complicated, but would that be more complicated than having to consider all possible schema/context providers through distinct properties?
Andra
On 26/09/2018 10:16, Andra Waagmeester wrote:
On Wed, Sep 26, 2018 at 9:47 AM James Heald jpm.heald@gmail.com wrote:
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.
Creating a dedicated property for schema.org, would also imply the need for creating designated properties for other context providers such as OBO, SIO, etc. I see that having to filter on matching uri providers in a single property can be complicated, but would that be more complicated than having to consider all possible schema/context providers through distinct properties?
In SPARQL the latter is very easy. Just make a VALUES list of all the properties you are interested in,
VALUES ?prop_wdt {wdt:P1111, wdt:P2222, wdt:P3333, wdt:P6666}
then look for
?item ?prop_wdt ?ext_id
Alternatively, if there is something characteristic about a whole set of properties that you want to use, then add that information to the wikidata item for the property. You will then be easily able to select all the with that characteristic, eg:
?prop wdt:1234 wd:Q5678901 ?prop wikibase:directClaim ?prop_wdt
This gives you the fine control to retrieve just the URIs of the services you want, rather than only being able to retrieve everything all lumped together.
Using distinct external-ID properties also makes it much easier to see what properties are currently in play, for project tracking pages like this one: https://www.wikidata.org/wiki/Wikidata:WikiProject_BHL/Statistics:Titles#Tit...
-- James.
--- This email has been checked for viruses by AVG. https://www.avg.com
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?
I object to this. "broad match" and "narrow match" are used to compare concepts, and "super class" and "subclass" to compare classes. It could make sense to say that C1 is a sub class of C2 if all instances of C1 are also instances of C2 even if the concept C1 is not related to C2.
I believe that not having a specific property for schema.org is actually more convenient. Having one would mean to use qualifiers to replace the different possible relations subClassOf, equivalentClass, superClassOf, subPropertyOf, equivalentProperty, superPropertyOf, narrowMatch, exactMatch and broadMatch and require people querying the data to always take care of them. Restricting to only schema.org is fast and easy in SPARQL with FILTER(STRSTARTS(STR(?url), "http://schema.org"))
Cheers,
Thomas
Le mer. 26 sept. 2018 à 11:45, James Heald jpm.heald@gmail.com a écrit :
On 26/09/2018 10:16, Andra Waagmeester wrote:
On Wed, Sep 26, 2018 at 9:47 AM James Heald jpm.heald@gmail.com wrote:
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.
Creating a dedicated property for schema.org, would also imply the need
for
creating designated properties for other context providers such as OBO, SIO, etc. I see that having to filter on matching uri providers in a
single
property can be complicated, but would that be more complicated than
having
to consider all possible schema/context providers through distinct properties?
In SPARQL the latter is very easy. Just make a VALUES list of all the properties you are interested in,
VALUES ?prop_wdt {wdt:P1111, wdt:P2222, wdt:P3333, wdt:P6666}then look for
?item ?prop_wdt ?ext_idAlternatively, if there is something characteristic about a whole set of properties that you want to use, then add that information to the wikidata item for the property. You will then be easily able to select all the with that characteristic, eg:
?prop wdt:1234 wd:Q5678901 ?prop wikibase:directClaim ?prop_wdtThis gives you the fine control to retrieve just the URIs of the services you want, rather than only being able to retrieve everything all lumped together.
Using distinct external-ID properties also makes it much easier to see what properties are currently in play, for project tracking pages like this one:
https://www.wikidata.org/wiki/Wikidata:WikiProject_BHL/Statistics:Titles#Tit...
-- James.
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
Hi,
aggregate demand -- broader external class --> https://schema.org/Demand
place of devotion -- broader external class --> https://schema.org/Place festival -- broader external class --> https://schema.org/Event
According to the "creator" of the property narrower external class (P3950) https://www.wikidata.org/wiki/Wikidata:Property_proposal/external_subclass, " the reverse (...) is less required because more general classes are more likely to be included in Wikidata anyway. "
These examples seem to prove him right, since "demand https://www.wikidata.org/wiki/Q4402708" exists in Wikidata and is already linked to "http://schema.org/Demand" via the equivalent class property. Same thing for https://schema.org/Event, already mapped with event https://www.wikidata.org/wiki/Q1656682, or for https://schema.org/Place , which could be associated with location https://www.wikidata.org/wiki/Q17334923 (not sure).
To be clear, I support the creation of "broader external class" because it can be used with some external vocabularies; I point this out just to make sure that all existing mapping possibilities are used. :)
Cheers,
Ettore Rizza
On Wed, 26 Sep 2018 at 03:53, Thad Guidry thadguidry@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 danbri@google.com wrote:
On Tue, 25 Sep 2018 at 16:35, Thad Guidry thadguidry@gmail.com wrote:
Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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
By the way: the item "demand https://www.wikidata.org/wiki/Q4402708" in Wikidata clearly refers to the economic concept in its broadest and most abstract sense, while https://schema.org/Demand is defined as "the public (...) announcement by an organization or person to seek certain types of goods or services. "
So I would not say they are equivalent classes, but rather something like < https://www.wikidata.org/wiki/Q4402708%3E skos:narrower < https://schema.org/Demand%3E.
As Andra Waagmeetser indicates, could not this be modeled with an external ID?
On Wed, 26 Sep 2018 at 10:18, Ettore RIZZA ettorerizza@gmail.com wrote:
Hi,
aggregate demand -- broader external class --> https://schema.org/Demand
place of devotion -- broader external class --> https://schema.org/Place festival -- broader external class --> https://schema.org/Event
According to the "creator" of the property narrower external class (P3950) https://www.wikidata.org/wiki/Wikidata:Property_proposal/external_subclass, " the reverse (...) is less required because more general classes are more likely to be included in Wikidata anyway. "
These examples seem to prove him right, since "demand https://www.wikidata.org/wiki/Q4402708" exists in Wikidata and is already linked to "http://schema.org/Demand" via the equivalent class property. Same thing for https://schema.org/Event, already mapped with event https://www.wikidata.org/wiki/Q1656682, or for https://schema.org/Place , which could be associated with location https://www.wikidata.org/wiki/Q17334923 (not sure).
To be clear, I support the creation of "broader external class" because it can be used with some external vocabularies; I point this out just to make sure that all existing mapping possibilities are used. :)
Cheers,
Ettore Rizza
On Wed, 26 Sep 2018 at 03:53, Thad Guidry thadguidry@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 danbri@google.com wrote:
On Tue, 25 Sep 2018 at 16:35, Thad Guidry thadguidry@gmail.com wrote:
Hi Team ! +Dan Brickley danbri@google.com +Lydia Pintscher lydia.pintscher@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