RE: Cover art rough proposal (was: Re: journal article for next call?)

Yes, journals and books (unless we're referencing online TOC via URL - where the plates are treated as a separate entry).

Again, if there is a way to isolate these images, that's great.  If not, I guess we'll have to accept the limitations as identified in previous message threads.

Thanks.

Tom

Tom Adamich, MLS
President
Visiting Librarian Service
224 Chauncey Ave. N.W.
P.O. Box 932
New Philadelphia, OH 44663
330-364-4410
vls@tusco.net


-----Original Message-----
From: Karen Coyle [mailto:kcoyle@kcoyle.net] 
Sent: Friday, November 29, 2013 1:09 PM
To: public-schemabibex@w3.org
Subject: Re: Cover art rough proposal (was: Re: journal article for next call?)

Another slippery slope, because I was thinking of 1) the icons in library catalogs that represent the media type (including "Online") and
2) the journals that publish plates and graphs found in the article on the same page as the abstract. (Which I believe is your case, Tom, right?)

kc

On 11/29/13 9:54 AM, Tom Adamich wrote:
> I agree with the distinctions being proposed for "cover".  Would there be additional designations for plates (which also often carry value as separate entities)?
>
> Tom
>
> Tom Adamich, MLS
> President
> Visiting Librarian Service
> 224 Chauncey Ave. N.W.
> P.O. Box 932
> New Philadelphia, OH 44663
> 330-364-4410
> vls@tusco.net
>
> -----Original Message-----
> From: Dan Scott [mailto:denials@gmail.com]
> Sent: Friday, November 29, 2013 11:17 AM
> To: public-schemabibex@w3.org
> Subject: Cover art rough proposal (was: Re: journal article for next call?)
>
> On Thu, Nov 28, 2013 at 6:39 PM, Dan Scott <denials@gmail.com> wrote:
>> On Thu, Nov 28, 2013 at 3:18 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>>>
>>>
>>> On 11/28/13 7:39 AM, Dan Scott wrote:
>>>
>>>>
>>>> Perhaps CreativeWork therefore gets a "cover" property with a range
>>>> of ImageObject that can be repeated; the ImageObject's "name"
>>>> property would then enable the repeated variants to be distinguished?
>>>
>>>
>>>
>>> Note:
>>>
>>> Thing has:
>>> image   URL     URL of an image of the item.
>>>
>>> and
>>>
>>> CreativeWork has:
>>> thumbnailUrl    URL     A thumbnail image relevant to the Thing.
>>>
>>> which I'm guessing could be a non-specific property that could
>>> include cover art on a book or DVD, as well as a thumbnail of an art work.
>>
>> Right, I saw those, but rejected them because they didn't allow for
>> any disambiguating properties. "thumbnailUrl" might have worked if it
>> wasn't tied so directly to a URL (in name as well as in range).
>> "image" could have its range extended to include ImageObject, I
>> suppose, although in that case you lose the distinction between any
>> other image included in a given creative work and the cover art which
>> holds a special place for many formats. My proposal of a "cover"
>> property with a range of ImageObject would allow the "name" property
>> to distinguish it, along with richer properties like "creator",
>> "description", etc.
>>
>>> I note that musicRecording has not specified a property for album
>>> art, and the examples don't show any use of that. (Aaargh! sometimes
>>> the examples don't see helpful.)
>>
>> MusicRecording is typically contained in http://schema.org/MusicAlbum,
>> which doesn't have any specific album art property either, and album
>> art is a key part of most music applications. So yes, I think "cover"
>> would apply nicely there, too, which is one of the reasons I scoped it
>> at the CreativeWork level.
>
> I should have noted that examples in  http://schema.org/Book and http://schema.org/MusicAlbum do currently use "image" for its cover art. Like Jeff, I'm far from happy with "URL" as the range of "image".
>
> So I would like to make the following proposals related to cover art (I'm on the way towards formalizing this in a wiki document, but putting this out for early review via email first):
>
> Whereas:
>
> a) books, music albums, magazines, comic books, and other creative works derive business value from publishing variant cover images ("cover art") for the same basic content;
>
> b) cover art is often considered a creative work in and of itself;
>
> c) cover art is often displayed on the web at a size much larger than a traditional thumbnail image and thus should be distinguished from thumbnail images;
>
> d) "thumbnailUrl" and "image" currently have a range limited to the data type "URL"
>
> e) the data type "URL" offers no means of employing additional metadata to distinguish variant covers, credit the creators of this cover art;
>
> f) "thumbnailUrl" currently does not appear in any of the published examples in the schema.org documentation;
>
> g) and "thumbnail", which has a range of "ImageObject" but currently has a domain restricted to "ImageObject" and "VideoObject"...
>
> Be it resolved that schema.org should:
>
> 1. Broaden the domain of "thumbnail" to include "CreativeWork";
>
> 2. Edit the "thumbnailUrl" property description to note that it is deprecated and that "thumbnail" is preferred;
>
> 3. Broaden the range of "image" to include both URL and ImageObject, so that images can have names, descriptions, and other data associated with them;
>
> 4. Update some of the current examples that use image with a plain URL (such as for Person and VideoObject) to use ImageObject instead;
>
> 5. Update some of the current examples that use "image" with a plain URL (such as CreativeWork) to instead use the "thumbnail" property with an ImageObject instead;
>
> 6. Create a new property, "coverArt", that is a subPropertyOf "image"
> and has a domain of Book, MusicAlbum, Periodical
>
> 7. Update some of the current examples that use "image" with a plain URL (such as Book, MusicAlbum, MusicRecording) to instead use the new "coverArt" property with an ImageObject, taking care to include at least one example of variant cover art;
>
> 8 Include at least one example of a "coverArt" ImageObject using the thumbnail property to also point at the thumbnail for the cover art
>
>
>
>

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

Received on Friday, 29 November 2013 18:39:48 UTC