Re: schema.org markup for a translated CreativeWork?

You're 100% right, that composability would be really useful, but we have
to draw a line somewhere as to how detailed we get with the data.  For
example, I'll use a show I'm currently (re-)watching (LOST):

There are no less than 4 languages: English, Korean, and Arabic.  Both the
Korean and Arabic speakers have English subtitles when they speak, and at
various points both speak English.

It wouldn't make sense to mark these up in most cases, but the ability to
mark the languages an actor performed in alongside the inLanguage property
of the actual show could probably provide enough detail.

Peter Lejeck

On Fri, Jun 27, 2014 at 9:18 AM, Simon Spero <sesuncedu@gmail.com> wrote:
> Anime can be thought of as a composite work; there is the video track, the
> audio tracks,  and the subtitle tracks. Since subtitles may come from
> different groups, composition is useful.
>
> Using this approach should make it easier to model, though the usual
> parallel list of performers may look ugly in microdata.
>
> Also,  am I the only one who keeps seeing yanderex.ru?
>
> On Jun 27, 2014 7:44 AM, "Peter Lejeck" <peter.lejeck@gmail.com> wrote:
>>
>> Hi,
>>
>> I'm a programmer working on Hummingbird.me, and I'm trying to mark up
>> our encyclopedia pages for anime series with microdata.  However, I'm
>> not sure how I should be marking up the actors by their language.
>>
>> There's basically two approaches I can think of, but neither seems
>> possible within the current properties:
>>
>> 1. Create multiple TVSeries for different languages, and put the actors
>> in each.  This is unambiguous in the odd cases where there are multiple
>> translations to a single language (I can think of at least one instance
>> in our database where this happened).  The inLanguage property already
>> eixsts to represent the language of a CreativeWork, I'd just need a way
>> to mark them as related works.
>>
>> 2. Add a language property to PerformanceRole.  This would obviously be
>> much simpler markup, but it would also add ambiguity to some cases.
>>
>> Am I overlooking something, or do you have suggestions for how to do
>> this?
>>
>> Thanks,
>> Peter Lejeck
>>
>>
>>
>

Received on Saturday, 28 June 2014 05:03:21 UTC