Discussion:
Mapping back to Schema.org needs "broader external class"
(too old to reply)
Thad Guidry
2018-09-25 23:34:56 UTC
Permalink
Hi Team !
+Dan Brickley <***@google.com> +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>
Thad Guidry
2018-09-26 01:53:29 UTC
Permalink
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>
Post by Thad Guidry
Hi Team !
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
Post by Thad Guidry
+ThadGuidry <https://plus.google.com/+ThadGuidry>
Andra Waagmeester
2018-09-26 05:57:36 UTC
Permalink
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?
Post by Thad Guidry
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>
Post by Thad Guidry
Hi Team !
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
Post by Thad Guidry
+ThadGuidry <https://plus.google.com/+ThadGuidry>
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
James Heald
2018-09-26 07:46:26 UTC
Permalink
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.
Post by Andra Waagmeester
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?
Post by Thad Guidry
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>
Post by Thad Guidry
Hi Team !
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
Post by Thad Guidry
+ThadGuidry <https://plus.google.com/+ThadGuidry>
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
---
This email has been checked for viruses by AVG.
https://www.avg.com
James Heald
2018-09-26 07:53:01 UTC
Permalink
Post by James Heald
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.
Post by James Heald
Post by Andra Waagmeester
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?
Post by Thad Guidry
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>
Post by Thad Guidry
Hi Team !
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
Post by Thad Guidry
+ThadGuidry <https://plus.google.com/+ThadGuidry>
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
---
This email has been checked for viruses by AVG.
https://www.avg.com
Andra Waagmeester
2018-09-26 09:16:56 UTC
Permalink
Post by James Heald
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
James Heald
2018-09-26 09:44:13 UTC
Permalink
Post by Andra Waagmeester
Post by James Heald
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#Titles_--_IDs

-- James.




---
This email has been checked for viruses by AVG.
https://www.avg.com
Thomas Pellissier Tanon
2018-09-26 15:39:23 UTC
Permalink
Post by Andra Waagmeester
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
Post by Andra Waagmeester
Post by Andra Waagmeester
Post by James Heald
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
Post by Andra Waagmeester
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
Post by Andra Waagmeester
property can be complicated, but would that be more complicated than
having
Post by Andra Waagmeester
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
?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
https://www.wikidata.org/wiki/Wikidata:WikiProject_BHL/Statistics:Titles#Titles_--_IDs
-- James.
---
This email has been checked for viruses by AVG.
https://www.avg.com
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
Ettore RIZZA
2018-09-26 08:18:59 UTC
Permalink
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
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>
Post by Thad Guidry
Hi Team !
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
Post by Thad Guidry
+ThadGuidry <https://plus.google.com/+ThadGuidry>
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
Ettore RIZZA
2018-09-26 08:41:47 UTC
Permalink
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> <skos:narrower> <
https://schema.org/Demand>.

As Andra Waagmeetser indicates, could not this be modeled with an external
ID?
Post by Ettore RIZZA
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
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>
Post by Thad Guidry
Hi Team !
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
Post by Thad Guidry
+ThadGuidry <https://plus.google.com/+ThadGuidry>
_______________________________________________
Wikidata mailing list
https://lists.wikimedia.org/mailman/listinfo/wikidata
Loading...