Re: cleaned up CommonEndeavor example

Hi Jeff,

On Mon, Jan 28, 2013 at 6:40 PM, Young,Jeff (OR) <jyoung@oclc.org> wrote:
> Here's some Monday a.m. philosophy (which I reserve the right to deny
> when Tuesday a.m. rolls around):
>
> Rather than explain what I'm trying to say, I'll wait to see how people
> interpret it.

I like this way of discussing modeling very much. By grounding in RDF,
where the semantics and concepts are well thought out and precise, the
risk of talking around each other regarding entity disambiguation or
identification is much lessened. Of course one has to grasp RDF and
subscribe to its semantics. But by doing so there is very little room
for reinvention of important core concepts, so that focus can be kept
on expressing the actual domain knowledge. "Just" syntax rarely
suffices, since it leaves room for implicit interpretation, which
commonly leads to conceptual confusion and semantic drift.

(Also, with RDF as a common base, different syntaxes simply aren't as
much of a barrier (other than reading speed). Turtle is by far the
most readable one, but descriptions using e.g. RDFa Lite are thus also
easy to grasp conceptually, since they are expressing RDF statements
directly.)

Now, to the topic at hand.

> <http://en.wikipedia.org/wiki/Pride_and_Prejudice_(1940_film)>
>         a schema:WebPage ;
>         schema:about
> <http://dbpedia.org/resource/Pride_and_Prejudice_(1940_film)>
>         .

This is how I have understood the relations as well. I think it
depicts the basic intent of what DBPedia IRIs identify – i.e. the
things described by the corresponding wikipedia articles. (AFAIK,
schema:about is equivalent to foaf:primaryTopic, which is commonly
used to express this relation. Case in point: see the RDF retrieved by
dereferencing the dbpedia IRI.)

> <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. 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..

> <http://www.worldcat.org/oclc/71794143>
>         a schema:ProductModel ;
>         x-schema:hasCarrier x-schema:DVD ;
>         x-schema:commonEndeavor
> <http://dbpedia.org/resource/Pride_and_Prejudice_(1940_film)> ;
>         owl:sameAs <http://isbn.org/isbn/9781419838231>;
>         .
>
> <http://www.worldcat.org/oclc/37633433>
>         a schema:ProductModel ;
>         x-schema:hasCarrier x-schema:VHS ;
>         x-schema:commonEndeavor
> <http://dbpedia.org/resource/Pride_and_Prejudice_(1940_film)> ;
>         owl:sameAs <http://isbn.org/isbn/9780792835844> ;
>         .

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.

[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_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
>> >>
>> >
>> >
>> >
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>
>
>

Received on Monday, 28 January 2013 20:52:20 UTC