RE: cleaned up CommonEndeavor example

Sorry, please retract my umbel:isLike suggestion. I misread the use case.

Jeff

> -----Original Message-----
> From: Young,Jeff (OR) [mailto:jyoung@oclc.org]
> Sent: Tuesday, January 29, 2013 9:29 AM
> To: kcoyle@kcoyle.net; Niklas Lindström
> Cc: public-schemabibex@w3.org
> Subject: RE: cleaned up CommonEndeavor example
> 
> > >> <http://dbpedia.org/resource/Pride_and_Prejudice_(1940_film)>
> > >>          a frbr:Work;
> > >>          .
> > >
> > > I suppose it is reasonable to conceive of this resource, the film,
> > > as being a frbr:Work, albeit the often(?) hazy distinction between
> > > Work and Expression has made me lean towards the latter when in
> doubt.
> 
> The only dividing line between Work/Expression I find easy to
> understand is concern for the language of expression. I don't think the
> Wikipedia/DBpedia resources generally divide along those lines, which
> is why I was inclined to tag it as a Work.
> 
> > Now,
> > > I am very much a library newbie, but I've come to think of Work as
> > > seemingly close to the skos:Concept class -- i.e. classifying a
> very
> > > loose conceptual subject. But that's probably another discussion.
> >
> > As I have said before, if FRBR worked in real life, we wouldn't still
> > be discussing it in every forum. In the library world, different
> > materials get different judgments. If you translate a text to a new
> > language, it's the same work, a new expression. If you update a
> > textbook to a new edition (but same title and author) it's the same
> > work, a new expression. However, the film community considers each
> new
> > rendering of a story as a movie to be a new work (and the director's
> > cut is also a new work). In addition, a book and movie cannot be the
> > same work. This, of course, has led some to postulate the need for a
> > "super-work."
> 
> I agree that the WEM pattern is squishy and subjective, but I don't
> think that means they aren't useful. It just means they have to be take
> with a grain of salt. I think that Niklas might have put his finger on
> it by suggesting that Work is close to skos:Concept. This would allow
> it to be attached to an identifiable skos:ConceptScheme, which could
> help contextualize the fuzziness. For example, OCLC has a Works
> algorithm that could be conceptualized as a skos:ConceptScheme and then
> all the Works that it deduces could be bound to it via skos:inScheme.
> 
> > Honestly, if it worked, we'd be doing it. I'm not terribly hopeful.
> 
> I suspect that it hasn't worked so good in the past is because people
> are creating "worksets" of MARC records rather than deconstructing the
> MARC records into a sensible model and then applying Map/Reduce to
> these higher-res resources. (Karen hints at this below.)
> 
> > > Is this how :commonEndeavor is intended to work? I would have
> > expected
> > > the proposed :instanceOf to be suitable here, and that
> > :commonEndeavor
> > > is more for relating two manifestations by implying a common,
> shared
> > > abstract notion of a work.
> >
> > Yes, what you say here is the intention.
> 
> My mistake. I should have looked closer at how commonEndeavor was being
> used.
> 
> > Here's the use case: you are a
> > library and you have two copies of Moby Dick. Your cataloging system
> > does not contain an identifier for a work at this moment in time.
> > Rather than being forced to find or create a Work description with an
> > IRI, you can say: these have essentially the same content. Or your
> > system can be smart enough to cluster "like" things for the
> > convenience of the user.
> > ("That one is checked out. How about this one?") It's a kind of
> > "mostLikelySameAs"
> 
> I recommend using umbel:isLike for this.
> 
> Jeff
> 
> > for the content of creative works. (The ISTC identifier,[1] when it
> > proliferates, will give us something more precise, but only for
> > texts.) It is purposely vague as a relationship, because unless you
> > have digital items and can do a byte-wise compare, it's hard to
> > quantify what differences will make a difference to a particular
> user.
> >
> > It is not unlike what OCLC does with its xISBN service[2], AFAIK,
> > where you send in the ISBN for one publisher's product with the text
> > of something like Moby Dick and you get back OCLC's best guess of
> > books containing the same text but with different ISBNs. It is a set
> > of like things, but with no middle, and no identifier for what they
> > have in common (the Work or the Expression). It seems to vary from
> > VIAF [3] only in this latter manner - VIAF clusters name authority
> > records from libraries, with none of them given predominance, but it
> > does create an identifier for the cluster. I think that as a
> practical
> > matter we may build the Work as a clustering of manifestations (is
> > this what FictionFinder does?)[4], and will give those clusters an
> > IRI, which will have a relationship to similar clusters from other
> > libraries or communities. Which means that I see the VIAF technique
> to
> > be one possible way to give users the services that FRBR Work
> promises
> > but without having to create a Work "record" for every work out there
> > (which is probably getting close to 100 million by now, at least
> using
> > the OCLC
> > studies.)
> >
> > kc
> > [1] http://www.istc-international.org/html/
> > [2] http://www.worldcat.org/affiliate/webservices/xisbn/app.jsp
> > [3] http://viaf.org
> > [4] http://www.oclc.org/research/activities/fictionfinder.html
> >
> > >
> > > [Edit: I just saw Antoine's reply, and it seems we think basically
> > the
> > > same things here. :) Posting anyway, to get this on record.]
> > >
> > > Cheers,
> > > Niklas
> > >
> > >
> > >> Jeff
> > >>
> > >>> -----Original Message-----
> > >>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> > >>> Sent: Sunday, January 27, 2013 10:56 AM
> > >>> To: Young,Jeff (OR)
> > >>> Cc: public-schemabibex@w3.org
> > >>> Subject: Re: cleaned up CommonEndeavor example
> > >>>
> > >>> Jeff, now that you mention this I am struck with grave doubts. ;-
> )
> > >>> The Wikipedia URI may be considered to represent the work, as
> > >>> would be dbpedia URI, but the Wikipedia page is not a
> > >>> commonEndeavor with the work. This is where we get back to your
> > >>> arguments about 303's -
> > -
> > >>> but I'm not convinced they save us in this case. The Wikipedia
> URI
> > >>> represents the topic AND the page, but can you say that a book is
> > an
> > >>> "instance" of a Wikipedia URI?
> > >>>
> > >>> Too philosophically difficult for Sunday a.m.
> > >>>
> > >>> kc
> > >>>
> > >>> On 1/26/13 7:30 PM, Young,Jeff (OR) 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_e
> > >>> x
> > >>>>> 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
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Karen Coyle
> > >>> kcoyle@kcoyle.net http://kcoyle.net
> > >>> ph: 1-510-540-7596
> > >>> m: 1-510-435-8234
> > >>> skype: kcoylenet
> > >>
> > >>
> > >>
> > >
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > ph: 1-510-540-7596
> > m: 1-510-435-8234
> > skype: kcoylenet
> >
> 
> 
>

Received on Tuesday, 29 January 2013 14:38:36 UTC