Re: Another example of Wikidata + schema.org for type enumerations

>> It's unfortunate that additionalType has such prominence on the
schema.org definition, I think that's what's confusing people.

> I think it confuses more people on this list than typical users of
schema.org. Multi-typed entities are an advanced case. It is not too
prominent on https://productforums.google.com/forum/.

You're obviously correct Martin when you say that proper handling of
handling of additional types "at the Microdata spec level is non-trivial,"
for the reasons you outline.

And yes, while multi-typed entities are *currently* an advanced case
without much prominence on the product forums, that will obviously change
if multi-typed entities are employed as a method of extending schema.org -
that is, thinking back to the notion of employing Wikidata enumerations
with which Dan started this thread, and the first line of code he used in
his example...

<div vocab="http://schema.org/" typeof="PlaceOfWorship
https://www.wikidata.org/entity/Q199451">

... obviously absent the issues surrounding additionalType, as this is RDFa.

And while extending schema.org itself falls into the advanced realm,
nailing down (and properly explaining) how multiple types are handled in
microdata is sort a predicate to pursuing the sort of external enumeration
mechanism Dan was wondering out loud about in this thread (and which I
think holds a lot of promise).



On Tue, Feb 25, 2014 at 4:33 AM, Jarno van Driel <jarno@quantumspork.nl>wrote:

> To be honest, what confuses me most aren't the multi-typed entities nor
> the external references themselves but the differences in the way one can
> declare them when making use of the different forms of markup, e.g.
> Microdata, RDFa (Lite), JSON-LD and so on.
>
> Now I understand schema.org can't be responsible for explaning how to use
> each form of markup in it's totallity but I do think it would be a good
> thing if schema.org tries to explan better what the differences between
> them are when it comes to using certain schema.org types, properties and
> numerations. And not just by means of a few code examples but also by means
> of a bit of theory, even if it is kept to a minimum.
>
>
> On Tue, Feb 25, 2014 at 11:33 AM, martin.hepp@ebusiness-unibw.org <
> martin.hepp@ebusiness-unibw.org> wrote:
>
>> Dear Stéphane:
>>
>> In addition to my last email:
>> > It's unfortunate that additionalType has such prominence on the
>> schema.org definition, I think that's what's confusing people.
>> I think it confuses more people on this list than typical users of
>> schema.org. Multi-typed entities are an advanced case. It is not too
>> prominent on https://productforums.google.com/forum/.
>>
>>
>> Best wishes / Mit freundlichen Grüßen
>>
>> Martin Hepp
>>
>> On 25 Feb 2014, at 03:16, Stéphane Corlosquet <scorlosquet@gmail.com>
>> wrote:
>>
>> >
>> >
>> >
>> > On Mon, Feb 24, 2014 at 8:39 PM, Jarno van Driel <jarno@quantumspork.nl>
>> wrote:
>> > Well for me the confusement started with a remark of GuHa:
>> "additionalType == typeOf" (
>> http://lists.w3.org/Archives/Public/public-vocabs/2013Oct/0136.html).
>> >
>> > Which got me to think that in case of additionalType one could write:
>> > <link itemprop="additionalType" href="http://schema.org/Type1
>> http://schema.org/Type2">
>> >
>> > Although Stéphane's remark: "href can only include one single URI" and
>> Martin's remark: "the type in here is a property value" do make perfect
>> sense from an HTML perspective.
>> >
>> > Now I looked at Dan's link to http://www.w3.org/TR/rdfa-syntax/#A-hrefand I've also looked it up in the Microdata specifications (
>> http://www.w3.org/TR/2013/NOTE-microdata-20131029/#values) and one could
>> argue that they do indicate a single URI. All be a bit technocratic. So IMO
>> I think it would be a good thing it schema.org could explain this a bit
>> more 'readable'.
>> >
>> > I hope my previous email shed more light on this.
>> >
>> > It's unfortunate that additionalType has such prominence on the
>> schema.org definition, I think that's what's confusing people. It's the
>> first property for all types due to the alphabetical order and it belongs
>> to Thing, while strictly speaking, it doesn't belong to the schema. You
>> don't need additionalType in many cases, because you can just add as many
>> types as you need in @typeof and @itemtype (with the limitation that all
>> have to belong to the same vocab  for @itemtype). additionalType is a
>> property that was introduced to work around a limitation of microdata, but
>> now I'm wondering if it's causing more confusion than anything else. Could
>> we bury it further down in the list? Looking at the discussions that led to
>> the introduction of additionalType to schema.org [1], it was essentially
>> to support the Good Relations use case in microdata where you have a main
>> product type from the GR namespace and a more specific type from another
>> namespace such as  http://www.productontology.org/id/Laser_printer. The
>> microdata syntax doesn't allow this natively (while RDFa does).
>> >
>> > Steph.
>> >
>> > [1] http://lists.w3.org/Archives/Public/public-vocabs/2012Jun/0031.html
>> >
>> >
>> >
>> > On Tue, Feb 25, 2014 at 2:24 AM, Thad Guidry <thadguidry@gmail.com>
>> wrote:
>> > This is probably going to be a FAQ question over and over and
>> over...so..
>> >
>> > We should probably annotate when something takes multiple values within
>> the schema somehow... hmmm.... something like... "only single value
>> allowed"  or  "doesn't support multiple values".
>> >
>> > Or is there already a hard and fast rule here in the schema... that
>> only Types can take multiple values ?
>> >
>> > Thoughts ?
>> >
>> > --
>> > -Thad
>> > +ThadGuidry
>> > Thad on LinkedIn
>> >
>> >
>> >
>> >
>> > --
>> > Steph.
>>
>>
>