Re: [a11y-metadata-project] Re: is/hasAdaption

On 10/7/13 4:20 PM, Niklas Lindström wrote:
> Hi Karen, all,
>
> Would that be roughly equivalent to dcterms:isFormatOf [1] ("A related
> resource that is substantially the same as the described resource, but
> in another format.")?

Yes, I believe that is the intention of dcterms:isFormatOf. Although, of 
course, the word "format" is another one of those that can have 
different meanings in different contexts. It would probably be best to 
make it clear that we are talking about a physical or digital format 
difference, not a difference between, say, a book and a movie, which 
some people might refer to as formats. (Of course, we're talking 
"carrier" in library-speak.)


>
> Whose meaning might be easier to grasp if it was called e.g.
> "alternateFormat", and was a symmetric property.. (Since
> dcterms:ifFormatOf/dcterms:hasFormat might otherwise kind-of work like
> exampleOfWork/workExample, albeit more narrow than our intentions are
> with the latter pair.)


I agree. I really prefer that we avoid things that have a specific 
directionality, where people have to decide whether A is a version of B, 
or B is a version of A. I prefer finding a way to say: A and B differ on 
characteristic X; are the same on characteristic Y.


>
> I believe that there is value in having all of isBasedOn, exampleOfWork
> and alternateFormat (or something like it, like the more general
> commonEndeavor). Or at least a similar constellation, and as long as the
> terms are clearly differentiated. The goal being to be general enough
> and cover a gamut of varied use cases, some using notions of
> generalizations, some representing chains of derivatives, and some
> building clusters of formats which represent the same content.

This is where use cases may get us further than continued discussion 
without them. I'm assuming, but cannot show you, that a certain amount 
of the problem will be solved by the basic descriptive metadata. For 
example, if you are looking for content by author, title or subject, 
your query should (in a 'good-enough' world) return all of the 
descriptions, regardless of format or accessibility options. And 
presuming that there is some metadata that describes the format or 
accessibility options, that could be included in the query if you 
specifically want, say, the PDF or the captioned film.

Where "alternativeFormat" seems to come in to this is where you want to 
confirm that item B is truly the same content as item A. This is getting 
VERY close to the concept of Work & Expression in FRBR, BTW, and 
currently those relationships are not so much coded in the metadata but 
inferred from the values present. This type of linking seems to me to be 
suited to a particular audience segment, and to a particular product 
line, like a database targeted at educators or persons with disabilities.

This makes me wonder about the extent to which this need for an explicit 
relationship is generalizable, or is a specific use case that will meet 
specific needs. Is it useful outside of the accessibility use case, or 
is the need covered well enough with data that is more likely to be 
supplied as part of the description? What is needed that cannot be done 
with description and query?

kc




>
> (For comparison, I believe that isBasedOn would be (more or less) a
> superproperty of dc:isVersionOf [2] and roughly equivalent to dc:source
> and prov:wasDerivedFrom [3]. See also some interesting in-depth
> comparisons at [4]. I prefer to explicitly relate to existing terms, if
> possible.)
>
> By the way, I think it'd be good to have the domain of exampleOfWork
> (and the domain and range of alternateFormat) explicitly include Product
> as well as CreativeWork. As we've seen in related threads, the more
> specific a work, the likelier that is is a tangible product of some
> sort, rather than the more general notion of the work (or, granted,
> being both).
>
> Cheers,
> Niklas
>
> [1]: http://purl.org/dc/terms/isFormatOf
> [2]: http://purl.org/dc/terms/isVersionOf
> [3]: http://www.w3.org/TR/prov-o/#wasDerivedFrom
> [4]: http://www.w3.org/TR/prov-dc/
>
>
> On Tue, Oct 8, 2013 at 12:15 AM, Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
>
>     Martin, library cataloging has the concept of "other formats" -- the
>     same thing in a different format. This has the advantage that you
>     don't have to decide which thing was adapted from which other thing,
>     only that they are the same content with different technologies.
>
>     I don't have a snappy name for it, but "other formats available"
>     seems to me to be the right concept.
>
>     kc
>
>
>     On 10/7/13 11:44 AM, martin.quiazon@gmail.com
>     <mailto:martin.quiazon@gmail.com> wrote:
>
>         For what it's worth, a little background on our experience
>         trying to describe the accessibility of our resources on
>         Bookshare.org: When we first tried to generate metadata for the
>         Learning Registry over a year ago, we started from Dublin Core
>         but found that there wasn't a commonly-used way to express these
>         kinds of content relationships. It was Liddy's work on the
>         Dublin Core accessibility module that led us to import
>         isAdaptationOf from the AfA vocabulary, so it seemed a good fit
>         to carry over into the a11y spec. If we didn't import
>         isAdaptationOf/hasAdaptation we'd probably have needed to
>         formulate something similar.
>
>         Since schema.org <http://schema.org> does have a wider charter,
>         I'm all for a term that's more universally applicable, but none
>         of the existing schema.org <http://schema.org> terms really
>         seems to satisfy the need here. isBasedOnUrl seems more properly
>         applied to new works that build/expand upon the referenced
>         resource. For example, at Bookshare, our books aren't derivative
>         or expanded works, they're alternatives that provide print books
>         via a different access mode. If I understand the definition of
>         sameAs, then I don't think it's appropriate either, since (for
>         example) a transcript of a recorded speech is not the same thing
>         as the speech.
>
>         Using workExample/exampleOfWork is an elegant solution, since
>         it's a good general-purpose property not limited to
>         accessibility. Anything that's useful to a wider range of
>         publishers is going to be more widely-adopted, which is a huge
>         plus. If acceptance into schema.org <http://schema.org> is
>         expected, then I'd be thrilled to use workExample/exampleOfWork
>         instead.
>
>         On Friday, October 4, 2013 9:52:00 AM UTC-7, matt.garrish wrote:
>
>                 and I think we would do better to wait on the exampleOfWork
>
>
>
>
>             I'd agree to this approach over using the existing
>             properties. I'd initially
>
>             read it as grouping manifestations of a single work, but
>             spotted this
>
>             sentence rereading:
>
>
>
>                 allowing for any schema:CreativeWork description to
>                 reference other
>
>
>                 CreativeWorks that it is an example/instance of
>
>
>
>
>             There is also a need to know which specific manifestation is
>             being adapted,
>
>             not just that there is a collection of related
>             manifestations to which the
>
>             current belongs. The obvious case being pagination in an
>             ebook, braille or
>
>             large print book. Bookshare, for example, probably doesn't
>             want to just tell
>
>             its clients that here is a manifestation of an overarching
>             work, but here is
>
>             a representation of this specific manifestation containing
>             its pagination
>
>             markers.
>
>
>
>             If the "work" can be a "manifestation" in this model, as
>             appears above, all
>
>             the good.
>
>
>
>             The ultimate usability will hinge on commonality of
>             identification. Provided
>
>             something easy like an ISBN for the user to search on,
>             alternatives could be
>
>             found, but if the reference is a fragment identifier within
>             a page probably
>
>             not so much. But then the existing property has that limitation.
>
>
>
>             Matt
>
>
>
>     --
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 <tel:1-510-435-8234>
>     skype: kcoylenet
>
>

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

Received on Tuesday, 8 October 2013 01:34:39 UTC