Re: cleaned up CommonEndeavor example

Sure. I'll get our data analyst to provide. It's not online yet. Ugh,
because no search (including retailer search) is currently willing to add
this criteria to its index. Because "nobody's using it". And very few
publishers are adopting ISTC right now because "nobody's using it".

And yet we continue to reinvent the wheel. Can you sense my frustration?

On 1/26/13 10:41 PM, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:

>Laura,
>
>Sorry, ISTC didn't come to mind because I'm barely aware of its
>existence. Any theory on this is a good theory. Is there some sample
>data available that we could examine?
>
>Jeff
>
>> -----Original Message-----
>> From: LAURA DAWSON [mailto:ljndawson@gmail.com]
>> Sent: Saturday, January 26, 2013 10:35 PM
>> To: Young,Jeff (OR)
>> Cc: <kcoyle@kcoyle.net>; <public-schemabibex@w3.org>
>> Subject: Re: cleaned up CommonEndeavor example
>> 
>> Please let's not forget ISTC?
>> 
>> On Jan 26, 2013, at 10:30 PM, "Young,Jeff (OR)" <jyoung@oclc.org>
>> wrote:
>> 
>> > Karen,
>> >
>> > The thought that a Wikipedia page could be considered to represent
>> the
>> > Work has been bugging me for awhile too. I've heard Roy Tennant use
>> > the term "Ground Truth" when it comes to mapping MARC to BIBFRAME.
>My
>> > feeling is that this Wikipedia comparison for Work is a credible
>> > variant of that.
>> >
>> > Jeff
>> >
>> >> -----Original Message-----
>> >> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
>> >> Sent: Saturday, January 26, 2013 2:44 PM
>> >> To: public-schemabibex@w3.org
>> >> Subject: Re: cleaned up CommonEndeavor example
>> >>
>> >> Jason, thanks for working on this. CommonEndeavor is a corollary to
>> > the
>> >> work/Instance proposal. Work/Instance assumes a hierarchy -- that
>> you
>> >> have a Work like "Moby Dick" that is published in many forms, and
>> >> that you have identifier for that Work that is more abstract than
>> any
>> >> of
>> > the
>> >> actual publications. For example, a Wikipedia page could be
>> >> considered to represent the Work, not any of the specific
>> >> publications. The Instance then is an Instance of that work.
>> >>
>> >> In many cases you do not have an identified "thing" for the Work,
>or
>> > at
>> >> least you don't have one handy at the time you are creating the
>> >> metadata. But you do, for example, have two different publications
>> of
>> >> Moby Dick and you know they represent the same content. So
>> >> "CommonEndeavor" (which may not be a good name for it) is a way of
>> >> saying that these two things share their creative content.
>> Eventually
>> >> these may be able to connect to a work and then they would become
>> >> instances of that work.
>> >>
>> >> On 1/26/13 11:04 AM, Jason Ronallo wrote:
>> >>
>> >>>
>> >>> Is there a URI for this Book? If so it could be used either as the
>> >>> value of the itemid attribute or as the value of the url property.
>> > If
>> >>> itemid is used in the example, then it would remove some blank
>> nodes
>> >>> in the RDF output. (Microdata processors that know about the
>> >>> Schema.org vocabulary should probably treat the url property in
>the
>> >>> same way. Schema.org promotes the url property instead of itemid
>> for
>> >>> some reason.) Even though the Schema.org examples don't use itemid
>> >>> there is no reason why we couldn't show better examples that do
>use
>> >>> the attribute.
>> >>
>> >> There could be a URI for the Books. Actually, there could be more
>> >> than one for each book since bibliographic data often gets a
>handful
>> >> of
>> >> identifiers: the identifier of the national library that originally
>> >> created the record, the identifier of OCLC when the record entered
>> > that
>> >> database, the identifier of the local library system where the
>> record
>> >> currently resides, as well as an ISBN. Which one is "the"
>identifier
>> >> that should be the URI for the book is not always clear. I tend to
>> >> favor the local system number from the system that most recently
>> >> exposed the bibliographic data as the "subject" URI, with the
>others
>> > as
>> >> additional identifiers.
>> >>
>> >> All that to say that I can easily make up a URI for each of these
>> >> items. :-)
>> >>
>> >>
>> >>>
>> >>> If commonEndeavor is a property of CreativeWork then the expected
>> >> type
>> >>> (as is given in the Overview section) should be a CreativeWork.
>> >>> Currently, how this parses is as a list of URLs (since the value
>of
>> >> an
>> >>> itemprop on an a element is the value of the href attribute). So I
>> >>> think the example is a poor one as it doesn't show how we'd like
>> > this
>> >>> to be used. This might in fact be the kind of data that publishers
>> >> end
>> >>> up creating, but the example we give should be more correct and
>> show
>> >>> more of the expressiveness.
>> >>
>> >> I'm afraid you lost me here. I copied a bunch of stuff from the
>> >> work/instance page [1] but had trouble fitting it into my example.
>> If
>> > I
>> >> have sufficiently explained the intention, please feel free to make
>> > the
>> >> example better. If not, contact me and I'm happy to work with you
>on
>> >> it.
>> >>
>> >>
>> >>>
>> >>> Is the CommonEndeavor proposal one that the group is still
>> >> considering
>> >>> pursuing?
>> >>
>> >> I believe it is still on the table, and so appreciate any work you
>> > wish
>> >> to do on it. As I say above, my main goal was to have a horizontal
>> >> relationship between bibliographic items in addition to the
>vertical
>> >> relationship of work/instance, especially when the Work information
>> >> isn't available (which at the moment it usually isn't). In current
>> >> library work there are a number of horizontal relationships being
>> >> considered:
>> >> - adaptation of (e.g. a book made into a movie; a children's
>version
>> > of
>> >> an adult text)
>> >> - translation of
>> >> - arrangement of (for music)
>> >>
>> >> etc. CommonEndeavor is kind of a catchall, and the more specific
>> >> relationships, where known, would be preferable.
>> >>
>> >> I don't feel strongly that we have to include this particular
>> >> vocabulary term, but I just don't think that we've got the data to
>> > make
>> >> much use of the hierarchical relationships at this time.
>> >>
>> >> kc
>> >>
>> >>
>> >>
>> >> If so, I can update the example to use the expected type for
>> >>> this property. I mainly just wanted to give an example of how the
>> >>> examples could be formatted to make it easier to evaluate them and
>> >>> show the tools used to generate the output. If there is a desire
>an
>> >>> RDFa Lite example with resulting RDF could also be created, though
>> > it
>> >>> ought to be very similar to the Microdata one.
>> >>>
>> >>> Jason
>> >>>
>> >>> [1]
>> >>
>> http://www.w3.org/community/schemabibex/wiki/CommonEndeavor#Simple_ex
>> >> a
>> >>> mple_showing_HTML_markup
>> >>
>> >> --
>> >> Karen Coyle
>> >> kcoyle@kcoyle.net http://kcoyle.net
>> >> ph: 1-510-540-7596
>> >> m: 1-510-435-8234
>> >> skype: kcoylenet
>> >
>> >
>> >
>
>

Received on Sunday, 27 January 2013 14:27:36 UTC