Re: Works and instances

On 07/01/2013 13:08, "Gordon Dunsire" <gordon@gordondunsire.com> wrote:

Comments in line below.

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

I think the schema description "The most generic kind of creative work,
including books, movies, photographs, software programs, etc." says it all.
>  
> 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?
> 
It is something we should use to test what we propose.  If we cannot
demonstrate how you would publish your data using [extended] Schema.org,
that is currently in FRBR/RDA/Marc/ISBD/etc., we will not have completed our
mission.
>  
> 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.
> 
We need to take into account what people are searching for, hence what the
search engines [behind schema.org] would hope to discern from data published
using the vocabulary.  My understand is that they want the works, with easy
paths to the manifestations/items.
> 
> 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².)
> 
Perhaps Œversion¹ & ŒversionOf¹  - is what we are looking for then....
> 
> 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.
> 
That may well help with mappings from Schema to RDA.
>  
> 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).
> 
I think that even this may be too restrictive for Schema ­ version &
versionOf would define the relationship.  If the CreativeWork was also
defined as a schema:Product that would by definition be a manifestation and
if it was defined as a schema:IndividualProduct that would imply it was an
item.
>  
> 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?
>  
How/where something is implemented/store using schema is down to the
implementer/data publisher/consumer. I suggest that if the [data] publisher
has knowledge of the relationships they should publish them ­ especially
when publishing as embedded RDFa/Microdata in web pages.  More links are
good.  If a search engine can group (manifestation level) descriptions by
the CreativeWork that they are versions of, it can provide a better service
to the users searching by work.

~Richard
> 
> 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
> 
>