W3C home > Mailing lists > Public > public-vocabs@w3.org > February 2012

Re: attachments to CreativeWorks

From: Dan Brickley <danbri@danbri.org>
Date: Wed, 29 Feb 2012 21:26:19 +0100
Message-ID: <CAFfrAFqN=Wbt8+3tahwt5v3k8EFi1udnHecb6Vk2fjqwT7kJ4g@mail.gmail.com>
To: Daniel Dulitz <daniel@google.com>
Cc: Jason Douglas <jasondouglas@google.com>, Will Norris <will@willnorris.com>, public-vocabs@w3.org
On 24 February 2012 00:51, Daniel Dulitz <daniel@google.com> wrote:
> Does anyone object to changing the description to make it clear that it is
> not a synonym for "encodings"? That seems to be the suggestion from this
> thread anyway.

Nobody objected. Let's fix it.

Resolved, we strike "This property is a synonym for encodings" from
definition of associatedMedia in http://schema.org/CreativeWork since
associatedMedia is broader and encompasses the notion of related
attachments. The 'encodings' property associated representations of
'the thing itself'.

I think we can do this now, without saying exactly which cases fall
best under 'encodings' vs 'associatedMedia'; there's a huge effort in
library world to model this for books and it's fiddly -
http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records
- whereas removing the 'synonym' clause is a nice quick fix.

Thanks Daniel,

Dan

> On Thu, Feb 23, 2012 at 12:52, Dan Brickley <danbri@danbri.org> wrote:
>>
>> On 23 February 2012 19:14, Jason Douglas <jasondouglas@google.com> wrote:
>> > On Tue, Feb 21, 2012 at 2:25 AM, Will Norris <will@willnorris.com>
>> > wrote:
>> >>
>> >> first couple, of what will likely be many, implementation questions:
>> >>
>> >> - how would folks recommend representing a short textual creative work
>> >> like a twitter post?  CreativeWork doesn't seem to have a place to put
>> >> the
>> >> body of the post, so would that then require the use of Article (so you
>> >> can
>> >> use articleBody)?  I guess for something like a tweet, you could
>> >> potentially
>> >> put the full message into the description of a generic CreativeWork,
>> >> but
>> >> that doesn't seem to work as well for longer posts like Google+
>> >> supports.
>> >>  By the way, is there a general rule of thumb that folks are using for
>> >> the
>> >> maximum length  a description value should be.
>> >
>> >
>> >  That's a good question.  I assume the markup needs to be included?
>> >  Unfortunately, I don't believe the microdata spec allows for picking up
>> > markup as part of a value.... but this seems like a common/important use
>> > case.
>>
>> That's my understanding of Microdata too. Also I don't think this is
>> handled in the [draft] Lite subset of RDFa 1.1, but full RDFa 1.1 does
>> allow it.
>>
>> >> - how would you represent supporting media objects for a creative work?
>> >>  For example, a photo that is part of a blog post.  At first glance,
>> >> associatedMedia looks like it would be the right property given its
>> >> name.
>> >>  However, the description states that it is a synonym for encodings,
>> >> which
>> >> throws me off a bit.  Personally, I reading encodings as being an
>> >> alternate
>> >> representation of the work (equivalent to a <link rel="alternate">).
>> >>  It's
>> >> exactly the same resource, only with a different encoding.  Based
>> >> simply on
>> >> the name, I read associatedMedia as being roughly equivalent to a <link
>> >> rel="enclosure"> or more generic <link rel="related">.  That is, it's a
>> >> different resource.
>> >
>> >
>> > That description doesn't make any sense to me either.  My understanding
>> > was
>> > Thing/image, CreativeWork/audio and CreativeWork/video were meant to be
>> > the
>> > representations of the object itself... and I would assume
>> > associatedMedia
>> > would be what you want.
>>
>> It seems the closest, but 'The media objects that encode this creative
>> work' throws me too. I think I share Will's expectation that
>> associatedMedia suggests "something else that goes along with this
>> thing". They're components or 'supporting parts' rather than encodings
>> of it. But yes, the property seems right; perhaps we could tweak the
>> description.
>>
>> cheers,
>>
>> Dan
>>
>
Received on Wednesday, 29 February 2012 20:26:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 06:48:59 GMT