Re: Extension syntax Was: Re: Updated Example

Ah, it's itemscope missing that bombs the validation. I had removed 
both. Which shows that there are some basic requirements for 
"well-formedness." I assume that there will be an attempt to create 
"good" microdata based on the standard.

No, there is no requirement that there be an "essential" type - and 
rarely does library data make such a distinction (that's why we have 
that gawdawful "kit"). I actually see the sub-types in schema.org as 
being human-facing -- helping people find the place in the schema where 
they are most likely to discover appropriate metadata properties, and 
giving them guidance. This is a much smaller list than the universe of 
Wikipedia, and I think that's a good thing. (I also am not thrilled by 
relying on Wikipedia's definitions or their division of the universe in 
all cases.)

As every class EXCEPT the Product class creates sub-classes for 
different types, and as CreativeWork has been developed in this way, I 
still vote for setting up a small number of types.

kc


On 2/28/13 9:44 AM, Young,Jeff (OR) wrote:
> Sorry, my example had some cruft in it. Here it is again:
>
> <div itemscope="">
>  <span itemprop="http://schema.org/name">Griffin</span>
> </div>
>
> The point is that itemtype isn't "essential". Furthermore there is no reason to assume that itemtype is the place where people should put the "essential" class and that the non-essential types belong in the "additionalType". We aren't even required to believe that things HAVE an essential type.
>
> http://en.wikipedia.org/wiki/Essentialism
>
> Jeff
>
>> -----Original Message-----
>> From: Young,Jeff (OR) [mailto:jyoung@oclc.org]
>> Sent: Thursday, February 28, 2013 12:35 PM
>> To: kcoyle@kcoyle.net; public-schemabibex@w3.org
>> Subject: RE: Extension syntax Was: Re: Updated Example
>>
>>> Like all schema.org properties, additionalType is optional in
>> instance
>>> data.  OTOH, Itemtype is required for the data to be recognized as
>>> microdata - at least, that's how it tests out at the Google rich
>>> snippets validation: the rich snippets won't show up properly without
>>> it.
>>
>> I don't think this is true. Here is a Microdata fragment that doesn't
>> have an itemtype that the Rich Snippet tool is able to parse without
>> complaint:
>>
>> <div itemprop="http://schema.org/publisher" itemscope="">
>>  <span itemprop="http://schema.org/name">Griffin</span>
>> </div>
>>
>> If the itemtype isn't included, it should be safe to infer
>> http://schema.org/Thing as the itemtype.
>>
>> This is inferable type the only "essential" that is needed. Beyond
>> that, there is no reason to think itemtype and additionalType have any
>> semantic differences at all. If an item has two types, it doesn't
>> matter which type goes in itemtype and which one(s) go in
>> additionalType.
>>
>> Jeff
>>
>>>
>>> Therefore, we need to think about what itemtypes are essential (as Ed
>>> said in an earlier email) since we can't be confident that
>>> additionalTypes will be used. Thus, if we think that eBook should be
>>> distinct from Book, then it will need to be an itemtype. If instead
>> we
>>> think that the distinction isn't important (or is optional) then we
>>> don't need an itemtype for eBook -- we would instead use Book and
>> some
>>> folks will include the optional additionalType for eBook. This is the
>>> distinction I am making -- that additionalType is optional, while
>>> itemType is not.
>>>
>>> Note that the Product folks have taken a very different approach from
>>> the rest of schema.org - there are no sub-classes under Product for
>>> the different product types, while there are lots of sub-classes
>> under
>>> "Event" and "Place" and the medical categories. etc. Instead the
>>> Product folks are relying on the additionalType added to the very
>>> generic "SomeProducts." This means that although it is called
>>> "additionalType"
>>> in many cases it will be the only real "type" information included,
>>> other than saying that it is a product. In examples that don't have
>> an
>>> additionalType the only thing identifying the product is the name or
>>> the description. By analogy, one could have no sub-classes under
>>> CreativeWork and use the productOntology to distinguish the types of
>>> creative works. That isn't the approach that was taken for
>>> CreativeWork or for classes other than Product, however.
>>>
>>> kc
>>>
>>>>> This is one of my concerns with the product ontology: if the
>>> information is essential to the microdata markup, it cannot be ONLY
>> in
>>> the additionalType. So where there is something like:
>>>>>
>>>>> Format: Audiobook on CD<br/>
>>>>>
>>>>> ... if we think that "CD" is an important bit of information for
>>> rich snippets or searching, then that needs microdata markup. The
>>> additional type statement:
>>>>>
>>>>> <link itemprop="additionalType"
>>>>> href="http://www.productontology.org/id/Compact_Disk"/>
>>>>>
>>>>> cannot be considered a substitute for markup of the display.
>>>>>
>>>>
>>>> Again I'm not seeing your point - are you trying to say that it is
>>> only valid to use text on display as property values?
>>>>
>>>> If you are, how does this, where the data asserting it is an
>>> Audiobook is embedded in an attribute, fit in with that?:
>>>>
>>>> <div itemscope itemtype="http://schema.org/Audiobook">
>>>> <span itemprop="name">Dune<span>
>>>> Format: Audiobook <br/>
>>>>
>>>>
>>>>
>>>>> Oddly enough, I am not finding examples where the carrier is
>> marked
>>> up *at all* - not even in the movie or recorded music schemas.
>>>>
>>>>
>>>> That does not surprise me - the rest of the world is less inclined
>>>> to
>>> categorise,  then group those categories, of things as  librarians
>> do.
>>>>
>>>> A tall ginger bloke is not often referred to as a man of height
>> type
>>> tall and hair colour red.
>>>>
>>>>> The Book schema uses this extension format, but with schema.org-
>>> defined terms:
>>>>>
>>>>> <link itemprop="bookFormat"
>> href="http://schema.org/Paperback">Mass
>>>>> Market Paperback
>>>>
>>>> Yes, thats what is described as an internal, to the vocabulary,
>>> enumeration.
>>>>>
>>>>> Which seems a bit odd to me, but I can understand that they didn't
>>> want to create a class for each of the book product types.
>>>>
>>>>
>>>> Exactly why they encourage external enumerations for sets of
>>> externally managed values, because Schema would not be able to
>>> effectively manage them.
>>>>
>>>> Product Ontology, for one is following this encouragement, as I
>>> believe should we.
>>>>
>>>> We after all are not expecting Schema to manage authoratitve lists
>>> subjects, names, etc - so why think it for format types?
>>>>
>>>>> (Although schema has numerous classes that add no new properties.)
>>>>>
>>>>> In any case, I think we need to create examples both with and
>>> without the extensions to make sure that our proposals work either
>> way.
>>>>
>>>>
>>>>
>>>> I'm all for providing examples of several ways of doing things. But
>>>> I
>>> get the feeling that you believe that some are more right than
>> others,
>>> or is that just a matter of personal preference?
>>>>
>>>>
>>>>>
>>>>>
>>>>> kc
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> ~Richard.
>>>>>>
>>>>>>>
>>>>>>> This is analogous to:
>>>>>>>
>>>>>>> <span itemprop="creator">John Smith</span>
>>>>>>>
>>>>>>> There may be something better to call it than "abridged" - but I
>>>>>>> couldn't think of anything at the time. I am in touch now with
>>> some
>>>>>>> audiobook publishers so I can ask them these questions. This
>>>>>>> information should not be in a general note, though, because it
>>> has
>>>>>>> particular significance for the sales of audiobooks. I'll ask my
>>>>>>> contacts for better terminology.
>>>>>>>
>>>>>>> kc
>>>>>>>
>>>>>>>
>>>>>>> On 2/23/13 10:10 AM, Richard Wallis wrote:
>>>>>>>> I read the abridged property as having a Boolean intent -
>>>>>>>> ³abridged² or ³unabridged²  - I was going to suggest ³yes²/²no²
>>> or
>>>>>>>> true/false as more appropriate ranges for such a property.
>>>>>>>>
>>>>>>>> Would not commonEndeavour  not be a better way to link an
>>> abridged
>>>>>>>> AudioBook and the Book it is an abridgement of?
>>>>>>>>
>>>>>>>> ~Richard.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 23/02/2013 16:30, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:
>>>>>>>>
>>>>>>>>       Karen has also proposed an abridged property with a range
>>>>>>>> of
>>> Text.
>>>>>>>>       It might be nice if the property was tweaked to have a
>>> domain and
>>>>>>>>       range of schema:Book so the link between the two could be
>>> followed.
>>>>>>>>
>>>>>>>>       Jeff
>>>>>>>>
>>>>>>>>       Sent from my iPad
>>>>>>>>
>>>>>>>>       On Feb 23, 2013, at 4:31 AM, "Richard Wallis"
>>>>>>>>       <richard.wallis@oclc.org> wrote:
>>>>>>>>
>>>>>>>>           Updated Example to reflect proposed Audiobook type Hi,
>>>>>>>>
>>>>>>>>           Following Karen posting a proposed Audiobook Type, I
>>> have
>>>>>>>>           updated the example in the Example Library to reflect
>>> it:
>>>>>>>>
>>>>>>>>
>> <http://www.w3.org/community/schemabibex/wiki/Examples/mylib/A8>
>>>>>>>>
>>>>>>>>           ~Richard.
>>>>>
>>>>> --
>>>>> Karen Coyle
>>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>>> ph: 1-510-540-7596
>>>>> m: 1-510-435-8234
>>>>> skype: kcoylenet
>>>>>
>>>>>
>>>
>>> --
>>> Karen Coyle
>>> kcoyle@kcoyle.net http://kcoyle.net
>>> ph: 1-510-540-7596
>>> m: 1-510-435-8234
>>> skype: kcoylenet
>>>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Thursday, 28 February 2013 18:39:31 UTC