Re: Extension syntax Was: Re: Updated Example

On 2/24/13 11:28 AM, Wallis,Richard wrote:

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

No, not at all. I'm saying that it would be best to extend schema in a
way that either properties with text and/or URI extensions can be used, 
but not just one. IMO this accommodates the greatest number of use 
cases. Since nothing in schema.org is required, this just opens up the 
possibilities.

Here's what we have in the library record that I used in my example:

500    Downloadable audio file
500    Unabridged
511 0  Read by Simon Prebble
520    The Jackal, the world's most cunning and revered assassin,
        is given a treacherous mission that could spell disaster
        for world diplomacy. Catching wind of a mysterious
        assassination plot, authorities throughout Europe mobilize
        a manhunt. However, without knowing the Jackal's true
        target, authorities are forced to wait until the clever
        killer makes his next move
538    Format: OverDrive MP3 Audiobook, OverDrive WMA Audiobook
538    Mode of access: World Wide Web
538    Requires OneClick Digital Media Manager
538    System requirements: 200 MB of free disk space, 512 MB of
        RAM, Windows Installer 3.1, Microsoft .NET Framework 4
        (x86 and x64), Windows Media Player 10 QA

As you see, there's no differentiation between "downloadable audio file"
and "unabridged", both being general 500 notes, nor between the four 538
fields. In fact, the only way to know it is an audio book (pre-RDA) is 
the GMD (245 $h):

245 14 The day of the jackal|h[downloadable audiobook] :|ba novel
        /|cby Frederick Forsyth

The fixed fields (007's) aren't much more help, and many
libraries don't code to that level of detail. So I think a broad 
property that can carry technical detail when it is present (538) may be 
best. So perhaps we could just use "schema.org/description" for 500's, 
and have a property for technical details (538 is "system details note").

ONIX, on the other hand, has a controlled list for everything under the 
sun. If you look at the ONIX codelists [1], codelist 81 is Product
Content Type, of which one is audiobook. Codelist 150 is Product Form of
which one is "CD audio" (there are various types of compact disks, of
which "audio" is one type) and another is "Digital download." Codelist
175 gives what ONIX calls "Product form detail" which includes things
like WMA, AAC, Ogg/Vorbis, DAISY, etc. Most of this information is 
present in the library record I used as an example, but not coded in the 
detail the way it would be in an ONIX record.

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

Actually, ONIX is much more detailed than what libraries provide -- it's 
schema.org that seems to be less precise. Not knowing the history of the 
individual schemas makes it hard to understand the use cases that 
informed them. When I look at the descriptions of actual products online 
they seem more detailed than what is in schema.org -- and necessarily 
so, since the different products have different prices and different 
delivery mechanisms. So I truly do not know why these schemas don't 
include that information. It's kind of hard to extend something when you 
don't know what the original developers were thinking.

>
> Exactly why they encourage external enumerations for sets of
> externally managed values, because Schema would not be able to
> effectively manage them.

I'm not advocating lists of values, just properties with text like

<span itemprop="techDetails">Format: OverDrive MP3 Audiobook, OverDrive 
WMA Audiobook</span>

or

<span itemprop="techDetails">Mode of access: World Wide Web</span>

Obviously you can't do with text what you can with controlled lists, but 
the information from which to derive a precise list member simply isn't 
there. I suppose it could all be coded as "description" but this 
technical note information seems to me to be different to a general 
description and it would be nice to bring out that quality.

>
> We after all are not expecting Schema to manage authoratitve lists
> subjects, names, etc - so why think it for format types?

Again, I'm not talking about authoritative lists. There is a property 
for Author and that doesn't require an authority controlled name. So I'm 
not advocating controlled lists, just a few more properties for the 
information that appears on the screen. Apart from the ONIX data, I 
really don't expect that there will be a lot of detailed controlled 
content. And although folks like Amazon and Audible may receive ONIX 
data from the publishers, what they display online seems to be much less 
detailed. (But I'm still hoping to talk to someone in the audiobook 
business about the data they do receive.)

kc
[1] 
http://www.editeur.org/files/ONIX%20for%20books%20-%20code%20lists/ONIX_BookProduct_CodeLists_Issue_20.html



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

Received on Monday, 25 February 2013 02:28:59 UTC