Re: Works and instances

My only concern is that the audience for this work is search engines, and
the audience for search engines is the consumer. So however we define
works/instances, it will have to be with an eye toward what the "average
user" will expect to find in search results.

We can raise the bar, but probably not to the degree we're accustomed to in
librariesŠ.

From:  Gordon Dunsire <gordon@gordondunsire.com>
Date:  Monday, January 7, 2013 8:08 AM
To:  <public-schemabibex@w3.org>
Subject:  RE: Works and instances
Resent-From:  <public-schemabibex@w3.org>
Resent-Date:  Mon, 07 Jan 2013 13:09:04 +0000

Re: Works and instances
All
 
The scope of schema's CreativeWork, ISBD's Resource, and Dublin Core's
BibliographicResource are all pretty much co-extensive:
 
schema:CreativeWork rdfs:comment "The most generic kind of creative work,
including books, movies, photographs, software programs, etc." .
isbd:C2001 rdfs:label "Resource" ;
 skos:definition "An entity, tangible or intangible, that comprises
intellectual and/or artistic content and is conceived, produced and/or
issued as a unit, forming the basis of a single bibliographic description."
;
 skos:scopeNote "Includes text, music, still and moving images, graphics,
maps, sound recordings and video recordings, electronic data or programs,
including those issued serially." .
dct:BibliographicResource skos:definition "A book, article, or other
documentary resource." .
 
ISBD Review Group has approved work on developing semantic relationships
between ISBD's Resource and FRBR's Group 1 (WEMI) classes. My very
preliminary thoughts are that only two properties are required to relate
Resource to WEMI:
 
isbd:hasExpression rdfs:label "has expression" ;
 rdfs:domain isbd:C2001 ;
 rdfs:range frbrer:C1002 .
frbrer:C1002 rdfs:label ³Expression² .
 
isbd:hasItem rdfs:label "has item" ;
 rdfs:domain isbd:C2001 ;
 rdfs:range frbrer:C1004 .
frbrer:C1004 rdfs:label ³Item² .
 
Properties are not required to relate Resource to Work or Manifestation,
because of the one-and-only-one cardinality constraint on Expression-Work
and Item-Manifestation. If an Expression, then a Work, and if an Item, then
a Manifestation.
 
Does this provide a way forward for schema.org to interoperate with
FRBR/RDA?
 
Practically, an instance of a CreativeWork is the resource/item being
marked-up, not something at a higher-level of abstraction, so I agree with
Karen¹s comment during the last telecom that instance=item, not
manifestation.
 
Relationships between different CreativeWorks can be based on the rich set
of existing relationships in FRBR and RDA. These can be dumbed-down to a
single generic relationship, but I  think it¹s ³relatedTo²  rather than
³versionOf², although it depends on the definition. Does ³version² cover
relationships like ³indexOf², ³successorTo², etc.?  (I agree that
³versionOf² is a better name than ³instanceOf².)
 
Note that RDA already has properties for such relationships between WEMI
entities which are unconstrained by WEMI domains and ranges, and the FRBR
Review Group has approved the publication of unconstrained FRBR properties
if and when the need arises.
 
The same goes for properties for WEMI attributes. So adding two more
properties, ³has Expression² and ³has Item², to schema.org would allow
FRBR/RDA data to be dumbed-down to schema. And this may help to resolve
content/carrier concerns, since ³has Expression² points to content
attributes (of Expression and Work), and ³has Item² points to carrier
attributes (of Item and Manifestation).
 
Finally, who uses these additional schema properties (including the two
proposed by Richard), and where are they ³stored²? Does schema expect
embedded markup to include relationships from the CreativeWork in hand to
other CreativeWorks, or for relationships to be added to harvested triples,
or both?
 

Cheers
 
Gordon
 

From: Richard Wallis [mailto:richard.wallis@oclc.org]
Sent: 07 January 2013 11:43
To: Karen Coyle; public-schemabibex@w3.org
Subject: Re: Works and instances
 
Karen,

I have much sympathy with your thoughts on the loose hooking together of
CreativeWorks with similar content ­ especially recognising that the
similarity is in the mind of those doing the hooking.  versionOf could be a
good replacement for instanceOf here.

Being immersed in the graph based world of linked data, I try to avoid (not
always with much success ;-) the use of structured hierarchical terms such
as vertical & horizontal, as they tend to precondition thinking.  versionOf
again may be useful here.

Having said all that, you only have to listen in on general conversation
between your colleagues, friends and relatives to realise that we all have
an implicit understanding of the concept of a creative work and [what us
frbr exposed folks would label] expressions and manifestations of that work
(without using those labels).

I contend that the majority of people start their journeys in the search
engines at that work level before drilling in to find what they are looking
for in terms of format, availability, etc. By not linking/identifying our
bibliographic resources at that level we are failing to get those resources
under the noses of the people looking for them.    To that end, I believe it
is worth striving towards providing the metadata capability to describe that
relationship, if the [data] publisher is aware of it.

~Richard.


On 06/01/2013 22:53, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
Richard, I would be more comfortable with a relationship property that
did not presume a hierarchy - that is, did not presume that one
description is subordinate ("instance of") another. My gut feeling is
that we will have many descriptions at various levels of detail, but
that there is no universal ordering that resembles WEMI.  Still, people
will want to say that *this* is similar to/another version of *that*. So
we'll have lots of citations of Tom Sawyer, most of which will include
publisher information, and people will want to hook them together. And
we might have movies and ebooks and audio books and various other things
that also have similar content. That "hooking together" constitutes a
Work in the minds of the "hookers" (:-)). But there may be no "Work"
description in the FRBR sense to point to. So I would prefer a
horizontal relationship property to a vertical one. Or, in fact, I would
prefer a property that allows people to make the relationship without
having to think any more about the relationship than "these are kind of
the same content."

And, no, I don't know what to call it. "versionOf" comes to mind, but is
not entirely satisfactory.

kc

On 1/6/13 1:35 PM, Richard Wallis wrote:
> Hi Karen,
>
> The key points I pick out of your well reasoned email are that there is no
> accepted definition of "workness", yet [it] would make sense to many people.
>
> Schema already includes a CreativeWork - it is an issue already being
> addressed by the wider community.  If we (the community who have probably
> have spent more time, effort, scholarly article pages, and conference
> sessions on the topic, than any other) can not help improve the approach, we
> will be missing a massive opportunity.
>
> Dare I suggest it would be too easy to over-think this, and put it onto the
> 'too difficult' pile.
>
> Both Painting & Sculpture are sub-types of CreativeWork.
>
> I agree that schema:manuscript is an omission and is something that should
> be discussed further (under the heading of content vs carrier ?).
>
> Back to 'instanceOf' and 'instance', I am not totally happy that they are
> the best property names (too much baggage inherited from other disciplines),
> but I have failed to come up with anything better.
>
> In my view schema:CreativeWork is aligned with frbr:Work as well as
> frbr:Expression, frbr:Manifestation, and probably frbr:Item - they all could
> be considered to be CreativeWork descriptions of more or less abstractness.
> If my assumption is a working one, an expression could be described (in
> Schema terms) as the instanceOf a Work as well as having an instance (the
> manifestation).
>
> Sorry for my slightly rambling response - its a bit late in the evening here
> ;-)
>
> ~Richard.
>
>
>
>
>
> On 06/01/2013 20:08, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>
>> I have been attempting for a while to respond to the definition of
>> properties relating works and instances. The problem may be that I have
>> been reading (too much?) about the work concept lately, and so I try to
>> cover too much ground.
>>
>> (Aside: recommended reading on the library concept of Work: Martha Yee's
>> four part series "What is a work?" [1] It is a relatively easy read,
>> there are examples, and the first part gives excellent historic background.)
>>
>> I will try to simplify with only a few comments:
>>
>> 1) "instanceOf" between two schema:creativeWork descriptions would only
>> be meaningful under certain conditions (e.g. one describes a work in the
>> abstract only), conditions which I consider to be (at this point in
>> time) unlikely to occur. Point 2 is one of the reasons for this opinion.
>>
>> 2) There is no accepted definition of "workness" even within the LAM
>> environment. cf. FRBRoo,[2] ISTC,[3] FaBIO, [4], not to mention BIBFRAME
>> [5], all of which differ from each other and from the description on
>> this group's wiki. (cf the example on the wiki, of 2 books and a movie,
>> is not aligned with FRBR:Work, but would make sense to many people).
>>
>> 3) It isn't clear to me whether works will be things (with identifiers),
>> post-description clusters (with or without IDs. a la' VIAF), or
>> relationships between bibliographic descriptions (e.g. "sameWork"
>> between two schema:Book descriptions)
>>
>> 4) The term "instance" for a mass-produced product is not helpful. It
>> could be applied to "singularities" like works of art, but not for
>> products. schema:creativeWork may describe both products and
>> singularities, without distinguishing which it is. Most schema:Book
>> descriptions will be manufactured products, but note that there is no
>> schema:manuscript. (schema:Painting and schema:Sculpture, which should
>> describe singularities, appear to be place-holders since they do not
>> extend schema:creativeWork.)
>>
>> Beyond this, it gets even more complex, and I do not believe that we can
>> resolve this at this time. My recommendation is that it is premature to
>> introduce this concept into schema.org. There are other relationships,
>> in particular the part/whole relationship that Richard also has included
>> on the wiki, that are more useful. We should concentrate on those.
>>
>> kc
>>
>>
>> [1] Linked from http://myee.bol.ucla.edu/workspub.htm
>> [2] http://www.cidoc-crm.org/frbr_inro.html
>> [3] http://www.istc-international.org/html/
>> [4] http://www.essepuntato.it/lode/http:/purl.org/spar/fabio
>> [5] http://www.loc.gov/marc/transition/news/bibframe-112312.html
>
>
>

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