Re: Extension syntax Was: Re: Updated Example

Karen,

Please excuse typos - I'm on an iPhone on a fast moving train.   ;-)


On 24 Feb 2013, at 16:48, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

> 
> 
> On 2/23/13 12:13 PM, Richard Wallis wrote:
> 
>> Although this is also syntactically correct:
>>     <span itemprop="abridged" value="false">UNABRRIDGED</span>
> 
> Richard,
> 
> This may be syntactically correct, but I can find no examples of communities using this type of syntax in the schema.org pages. (Of course, I may have missed something, but a search didn't turn any up.)

I wasn't suggesting that we promote the usage of this particular syntax - I was merely pointing out that it is possible to markup data values without being constrained by only being able to use what is on display. 



> I also find few examples using the extension syntax in their examples:
> 
> <a itemprop="readBy" href="http://viaf.org/viaf/33892908">Orlagh Cassidy</a>

I am surprised that you found few using href to link to a description of the name being displayed - that's just standard HTML isn't it?

> <link itemprop="additionalType" href="http://schema.org/Product"/>
> 
> While there may be some community members who will make use of this (OCLC being the obvious one), I think we need to be careful that our schema.org proposals produce a complete description without the external vocabulary extensions - those cannot be "mandatory" for the extraction of meaning, but need to be "added, more detailed information."

Not sure what you mean by this - additionalType was added to Schema because of the need to describe things to be of more than one type, which many real word things are. Unfortunately Microdata has a limitation  in this area, which RDFa does not, so this approach became a basic part of the vocabulary which we are proposing to extend. I see no reason not to use all of the vocabulary. 

> 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
> 
>

Received on Sunday, 24 February 2013 19:31:02 UTC