- From: Niklas Lindström <lindstream@gmail.com>
- Date: Sat, 21 Sep 2013 02:53:58 +0200
- To: Dan Scott <dan@coffeecode.net>
- Cc: Aaron Bradley <aaranged@gmail.com>, "Wallis,Richard" <Richard.Wallis@oclc.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>
- Message-ID: <CADjV5jcJgktH73eJJomuRr-NVk=UDVBvr4ArqKDxsovN916HhA@mail.gmail.com>
Hi Dan, On Fri, Sep 20, 2013 at 3:59 PM, Dan Scott <dan@coffeecode.net> wrote: > On Thu, Sep 19, 2013 at 07:47:54AM -0700, Aaron Bradley wrote: > >> I think this is a type whose time has come. >> >> I wonder, though, whether an "Audiobook" type should encompass - or at >> least try to account for - audio dramas. That is a dramatization rather >> than a reading of a book, or an original audio drama, such as one commonly >> encounters on public radio broadcasters like the BBC. >> >> Really the only property that would need to be re-examined in this light >> is >> "readBy", because of the difference between a "reading" and a >> "performance." >> >> For both audio books and audio dramas, the existing property performer [1] >> seems well-suited to the task. And even looking just at the type >> "AudioBook" it seems that "readBy" is an unnecessarily more specific >> version of "performer" (for example, there is no "actor" property for >> TheatreEvent [2]). >> > > I am sympathetic to this perspective. There is a vast set of potential > types of contributions to creative works that the current schema.org > vocabulary does not capture. For example, the long list of credits in > any given movie contains many different roles such as gaffer, key grip, > dressmaker, etc (http://www.imdb.com/title/**tt0111161/fullcredits<http://www.imdb.com/title/tt0111161/fullcredits>for > example). Distinguishing these various types of contribution > is worthwhile, but I'm sure we don't want to expand > http://schema.org/CreativeWork or its children to have named properties > for all of these possibilities. > > So, to kick an idea around, what if the range of "contributor" and > "performer" included a new type, "Contributor", which would consist of > two new properties: > > * participant (range: Organization, Person) > * contribution (range: http://schema.org/Contribution (new type with an > external enumeration) > > For the external enumeration, we could point to an existing vocabulary > like http://id.loc.gov/vocabulary/**relators.html<http://id.loc.gov/vocabulary/relators.html>; > this list includes many > types of contributions beyond what schema.org currently details, but it > is also missing a number just from the one film credit example above. > Alternately, we could go the ProductOntology route and use wikipedia > types like http://www.productontology.**org/id/Dressmaker<http://www.productontology.org/id/Dressmaker>and > http://www.productontology.**org/id/Gaffer_(filmmaking)<http://www.productontology.org/id/Gaffer_(filmmaking)>-- I suppose these > contribution types fall under "services", which explains why they're > mapped and enumerated. That said, > http://www.productontology.**org/id/Narrator<http://www.productontology.org/id/Narrator>redirects to "Narrative" (per > wikipedia), so PTO isn't a perfect option either. Would a union of both > external enumerations be possible (or does someone have a better > existing vocab in mind)? > > I'm not keen on "participant" as the property name for the new type, but > "contributor" is already taken--heh. Having a "contributor" property and > "Contributor" type might be bad form, as well. This is far from a full > proposal! > > In the specific case of satisfying the desire for an Audiobook "readBy" > property, the RDFa would look like: > > <p property="contributor" typeof="Contributor">Read by: <span > property="participant" typeof="Person">Simon Prebble</span> > <meta property="contribution" content="http://id.loc.gov/** > vocabulary/relators/nrt <http://id.loc.gov/vocabulary/relators/nrt>"> > </p> > > I believe this is a direction worth exploring, but would not be > surprised if it had already been discussed and dismissed... if the > latter, then my apologies for wasting bandwidth. Surely worth considering. So you didn't waste my bandwidth at least. :) I would prefer a direct description using multiple properties though. Like: <p vocab="http://schema.org/" prefix="lcrel: http://id.loc.gov/vocabulary/relators/" typeof="Audiobook"> Read by: <span property="contributor lcrel:nrt" typeof="Person"> <span property="name">Simon Prebble</span> </span> </p> (Of course, I also would like a future when using only lcrel:nrt was possible, due to having it declared as rdfs:subPropertyOf sdo:contributor. And by possible I mean the search engines using such information. Today, lcrel:nrt is already declared as rdfs:subPropertyOf dc11:contributor. Which at least could have a formal relation to sdo:contributor (today there is [1]).) Though if you'd like to investigate corresponding qualified associations, I recommend looking at the PROV vocabulary, especially prov:qualifiedAssociation [2]. (Well, glancing at it and pondering if there are portions that could fit the scope of schema.org.) Cheers, Niklas [1]: https://raw.github.com/dcmi/schema.org/master/mappings_schema.org.xml [2]: http://www.w3.org/TR/prov-o/#qualifiedAssociation > > > Dan > >
Received on Saturday, 21 September 2013 00:54:56 UTC