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:29:39 UTC