Print

Print


On 12/4/15 8:22 PM, Steven Folsom wrote:
> [I think I may have turned others off by keeping this thread going so 
> long, but I’ll respond openly in case someone has more to add… a 
> counter point… etc.]
>
> carrier: would be the prefix for http://id.loc.gov/vocabulary/carriers 
> <http://id.loc.gov/vocabulary/carriers/sd>. carrier:sd is then short 
> for <http://id.loc.gov/vocabulary/carriers/sd>, the URI for audio disc.
>
> A general carrier:Carrier class could be said to be owl:sameAs 
> bf:Instance, and then any subclass of carrier:Carrier would also then 
> be the subclass of bf:Instance.

This assumes that a hard copy and a pdf of the same item would be 
different instances, no? What about a DVD and a Blueray of the same 
movie? Or a ePub and Kindle edition? Although bf:Instance is defined as 
being the "carrier" (conceptually) I don't think that it actually does 
coherently represent the physical carrier. It's really a mish-mosh of 
things we've called "descriptive cataloging", more or less equivalent to 
ISBD. But as we know that fell apart with digital equivalents and I 
don't think it's been resolved. I actually think that Instance needs to 
be better analyzed, and we might end up with two or more sets of data - 
separating the bibliographic description and the physical description.

I could, however, get behind an attempt at subclassing bf:Work such that 
ex:Poem and ex:Symphony, etc., could be works. In the end bf:Work is an 
abstract super-class that itself may never need to be instantiated. And 
maybe the same would be true of Instance once we separate bibliographic 
and physical attributes. The entire FRBR WEMI is at a level of 
abstraction that is nearly meaningless, so "edition" and "performance" 
actually could infer frbr:Expression, and no one would need to assign 
those abstractions.

Hmmm. Worth thinking about. Thanks for the stimulus.

kc



>
> The advantage is that if someone said: <SomeWork> bf:hasInstance 
> <SomeRDFResource> . … it could be inferred that <SomeRDFResource> a 
> <bf:Instance>, <carrier:Carrier> . Both classes wouldn’t have to be 
> directly asserted because the range of bf:hasInstance is bf:Instance, 
> and bf:Instance is the sameAs carrier:Carrier. Also, ontology 
> engineers/RDA practitioners would be confident that it’s ok to use 
> Carriers as bf:Instance subtypes. It makes the semantic intent clearer 
> for both classes, ensuring appropriate ontology reuse.
>
> The disadvantage is the ontological commitment of saying 
> <carrier:Carrier> owl:sameAs <bf:Instance>. There may be cases (I 
> truly don’t know, but can’t think of any) where a Carrier type isn’t 
> an Instance type. The way I think of Instance and Carrier types is 
> that they are types of artifacts that carry bf:Works. If I’m wrong, 
> and Instances and Carriers don’t always have the same meaning… then 
> you don’t want to have the owl:sameAs assertion between 
> carrier:Carrier and bf:Instance.
>
> Again, thanks for the open discussion,,
> Steven
>
> ————
> Steven Folsom
> Metadata Strategist and Standards Advocate
> Cornell University Library
>
>
> From: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>> on 
> behalf of "Denenberg, Ray" <[log in to unmask] <mailto:[log in to unmask]>>
> Reply-To: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Date: Friday, December 4, 2015 at 10:20 AM
> To: "[log in to unmask] <mailto:[log in to unmask]>" 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Subject: Re: [BIBFRAME] Categories proposal
>
>     In other words, we could say:
>
>     <http://id.loc.gov/vocabulary/carriers/sd> a  bf:Instance,
>     carrier:sd  ;
>
>     (Where ‘carrier:sd’  is a prefix for
>     http://id.loc.gov/vocabulary/carriers
>     <http://id.loc.gov/vocabulary/carriers/sd> .)
>
>     Where http://id.loc.gov/vocabulary/carriers/sd
>     <http://id.loc.gov/vocabulary/carriers/sd> is NOT  declared to be
>     a subclass of bf:Instance.
>
>     (And of course as you suggest these would never be declared disjoint.)
>
>     Which all makes sense to me and my question would be, what
>     advantage then, if any, is there to making
>     http://id.loc.gov/vocabulary/carriers/sd
>     <http://id.loc.gov/vocabulary/carriers/sd> a subclass of bf:Instance.
>
>     Ray
>
>     *From:*Bibliographic Framework Transition Initiative Forum
>     [mailto:[log in to unmask]] *On Behalf Of *Steven Folsom
>     *Sent:* Thursday, December 03, 2015 8:51 PM
>     *To:* [log in to unmask] <mailto:[log in to unmask]>
>     *Subject:* Re: [BIBFRAME] Categories proposal
>
>     In a closed system (relational db, etc.) or even a triplestore I
>     could use an ID URI and say as much as I want about it, but if I
>     wanted to publish the information as linked data through a
>     dereferenceable URI, either I need to be able to write to the ID
>     server, or I need to write the data to a local (or other global)
>     domain that I have access to. Another way to say it is I can’t
>     publish data to http://id.loc.gov/vocabulary/carriers/sd
>     <http://id.loc.gov/vocabulary/carriers/sd.html> because I don’t
>     have access to it. Instead, I would have to have access to a
>     system with a different URI for the same thing and assert a sameAs
>     relationship.
>
>     No, I wasn’t trying to say all subclasses of Work and Instance
>     would have to be included in ID. Part of the open world assumption
>     and ontology reuse is that someone can extend ontologies for
>     themselves. I hope they/we do; it’s a sign of a good ontology if
>     others are reusing it. What I was suggesting is that if ID decides
>     that they do want to always consider the Content and Carrier types
>     as subclasses of Works and Instances respectively, they/you could.
>     If not, the Content and Carrier types don’t have to be treated
>     formally as subclasses. One could still say a particular thing is
>     both an Instance and Carrier as long as the classes aren’t
>     asserted to be disjoint. Interoperability is just easier if the
>     alignment is asserted in ontologies, assuming the semantics make
>     sense.
>
>     If/when libraries start creating/consuming BIBFRAME, schema.org,
>     etc. in concert these alignments will become more and more important.
>
>     Thanks for the continued conversation,
>
>     Steven
>
>     *From: *Bibliographic Framework Transition Initiative Forum
>     <[log in to unmask] <mailto:[log in to unmask]>> on
>     behalf of "Denenberg, Ray" <[log in to unmask] <mailto:[log in to unmask]>>
>     *Reply-To: *Bibliographic Framework Transition Initiative Forum
>     <[log in to unmask] <mailto:[log in to unmask]>>
>     *Date: *Thursday, December 3, 2015 at 5:56 PM
>     *To: *"[log in to unmask]
>     <mailto:[log in to unmask]>" <[log in to unmask]
>     <mailto:[log in to unmask]>>
>     *Subject: *Re: [BIBFRAME] Categories proposal
>
>         Sorry, I spoke too fast, didn’t mean to say
>
>         <http://id.loc.gov/vocabulary/carriers/sd> a  bf:Instance.
>
>         But rather
>
>         <http://id.loc.gov/vocabulary/carriers/sd> rdfs:subClassOf
>         <bf:Instance>
>
>         I’m not quite sure why your assertion would be lost (without
>         ID making the same assertion), but let’s say it’s so. 
>         Theoretically, we could add the assertions to ID.  (I say
>         “theoretically” because I cannot commit to that, we’d have to
>         discuss it, and I haven’t discussed it yet here.)   But if we
>         take that approach then are we saying that all potential
>         subclasses of Work or Instance would have to be included in
>         ID?  (Because we can’t assume that other vocabularies with
>         potential subclasses of Work or Instance will include these
>         assertions.)
>
>         Hope I’m understanding you correctly, and I appreciate your
>         persistence in this issue.
>
>         Ray
>
>         *From:*Bibliographic Framework Transition Initiative Forum
>         [mailto:[log in to unmask]] *On Behalf Of *Steven Folsom
>         *Sent:* Thursday, December 03, 2015 4:52 PM
>         *To:* [log in to unmask] <mailto:[log in to unmask]>
>         *Subject:* Re: [BIBFRAME] Categories proposal
>
>         Ray,
>
>         [Sorry, I’m not trying to be a nag.] What I’m trying to say is
>         that the following IS an implementation of RDA because it
>         provides category, carrier and media information about the
>         library resource.
>
>         <http://bibframe.example.org/instance/xyz>  a
>          <http://id.loc.gov/vocabulary/carriers/sd> ,
>          <http://vocab.getty.edu/aat/300265800> .
>
>         <http://id.loc.gov/vocabulary/carriers/sd> rdfs:subClassOf
>         <bf:Instance> ;
>
>         bf:hasMedia <http://id.loc.gov/vocabulary/mediaTypes/s> .
>
>         Notice here that I’ve asserted that the audio disc carrier is
>         a subclass of bf:Instance (which is different from saying it
>         is an individual of a bf:Instance) and that it has audio as a
>         media. In a linked data environment, I can’t really say these
>         things without minting my own URI for for the concept of audio
>         disc carrier and stating that it’s the sameAs ID’s. Without ID
>         making those same assertions on it’s URI, when someone
>         resolved to it, my assertions would be lost.
>
>         Thanks,
>
>         Steven
>
>         ————
>
>         Steven Folsom
>
>         Metadata Strategist and Standards Advocate
>
>         Cornell University Library
>
>         *From: *Bibliographic Framework Transition Initiative Forum
>         <[log in to unmask] <mailto:[log in to unmask]>>
>         on behalf of "Denenberg, Ray" <[log in to unmask] <mailto:[log in to unmask]>>
>         *Reply-To: *Bibliographic Framework Transition Initiative
>         Forum <[log in to unmask]
>         <mailto:[log in to unmask]>>
>         *Date: *Thursday, December 3, 2015 at 3:29 PM
>         *To: *"[log in to unmask]
>         <mailto:[log in to unmask]>" <[log in to unmask]
>         <mailto:[log in to unmask]>>
>         *Subject: *Re: [BIBFRAME] Categories proposal
>
>             Steven – RDA is not one of my strong points (to put it
>             mildly) so I’m afraid I’m not going to be able to offer
>             any insight, but others here might weigh in.
>
>             You’re certainly correct that the set of built-in Work and
>             Instance subclasses is not intended to describe all
>             possible Work and Instance types.  So let’s say you want
>             to describe some Instance as being of type
>             http://id.loc.gov/vocabulary/carriers/sd .  Certainly you
>             can do that.
>
>             http://id.loc.gov/vocabulary/carriers/sd.rdf already
>             defines it to be a class. Though is does not define it to
>             be a BIBFRAME Instance, you could say:
>
>             <http://bibframe.example.org/instance/xyz>  a 
>             (http://id.loc.gov/vocabulary/carriers/sd> .
>
>             <http://id.loc.gov/vocabulary/carriers/sd> a  bf:Instance.
>
>             Sorry, I did not mean to imply that you could not do
>             that.  I was simply saying that the ability to do this
>             would not obviate the need to support the method described
>             in the category proposal.
>
>             Ray
>
>             *From:*Bibliographic Framework Transition Initiative Forum
>             [mailto:[log in to unmask]] *On Behalf Of *Steven
>             Folsom
>             *Sent:* Thursday, December 03, 2015 10:42 AM
>             *To:* [log in to unmask]
>             <mailto:[log in to unmask]>
>             *Subject:* Re: [BIBFRAME] Categories proposal
>
>             Ray,
>
>             Thanks for the response. I’m curious about your thoughts
>             on implementing RDA in BIBFRAME and extending BIBFRAME
>             going forward.
>
>             RDA is a content standard (independent of how it is
>             serialized). To my knowledge there nothing prescriptive in
>             RDA explaining how to implement it MARC; similarly we are
>             left to decide how to implement it in BIBFRAME.
>
>             In RDF classes are used to say some individual thing is a
>             certain type of thing. We don’t need a separate
>             property/pattern; we just say it is that type of thing
>             using rdf:type. A specific bf:Work refers to an individual
>             of a type/s of intellectual content, and a specific
>             bf:Instance refers to an individual of a type/s of
>             material embodiments (carriers) of the Work. Right?
>
>             Yes, there are the built in bf:Work and bf:Instance
>             subclasses, but clearly they are not enough to
>             sufficiently describe with specificity Work and Instance
>             types. We’ll need to extend BIBFRAME using classes defined
>             elsewhere… with The Getty AAT, RDA Content/Carrier Types, etc.
>
>             To have multiple ways to query whether something is a type
>             of thing (through classes/subclasses and the category
>             patterns) doesn’t seem necessary.
>
>             Respectfully,
>
>             Steven
>
>             ————
>
>             Steven Folsom
>
>             Metadata Strategist and Standards Advocate
>
>             Cornell University Library
>
>             *From: *Bibliographic Framework Transition Initiative
>             Forum <[log in to unmask]
>             <mailto:[log in to unmask]>> on behalf of
>             "Denenberg, Ray" <[log in to unmask] <mailto:[log in to unmask]>>
>             *Reply-To: *Bibliographic Framework Transition Initiative
>             Forum <[log in to unmask]
>             <mailto:[log in to unmask]>>
>             *Date: *Wednesday, December 2, 2015 at 3:45 PM
>             *To: *"[log in to unmask]
>             <mailto:[log in to unmask]>"
>             <[log in to unmask] <mailto:[log in to unmask]>>
>             *Subject: *Re: [BIBFRAME] Categories proposal
>
>                 There are several subclasses of bf:Work and there are
>                 subclasses of bf:Instance.  (Both are listed below for
>                 1.0, and BIBFRAME 2.0 will similarly have subclasses
>                 of Work and Instance although they might not be
>                 exactly the same.)
>
>                 The Work subclasses overlap to some extent with
>                 content values  - “text” for example. For the Instance
>                 subclasses there is very little (if any) overlap with
>                 the carrier values.
>
>                 So, no, I don’t think that these content and carrier
>                 values can be instantiated as Work and Instance
>                 subclasses.
>
>                 Content, carrier, and media are essentially RDA
>                 concepts and the main purpose of these in BIBFRAME is
>                 support for RDA.  The inclusion of these within
>                 BIBFRAME RDF is completely optional and those with no
>                 interest in RDA probably will not include this
>                 information.
>
>                 *Subclasses of bf:Work (1.0)*
>
>                 Audio
>
>                 Cartography
>
>                 dataset
>
>                 MixedMaterial
>
>                 MovingImage
>
>                 Multimedia
>
>                 NotatedMovement
>
>                 NotatedMusic
>
>                 StillImage
>
>                 Text
>
>                 ThreeDimensionalObject
>
>                 *Subclasses of bf:Instance (1.0)*
>
>                 Archival
>
>                 Collection
>
>                 Electronic
>
>                 Integrating
>
>                 Manuscript
>
>                 Monograph
>
>                 MultipartMonograph
>
>                 Print
>
>                 Serial
>
>                 Tactile
>
>                 Ray
>
>                 *From:*Bibliographic Framework Transition Initiative
>                 Forum [mailto:[log in to unmask]] *On Behalf Of
>                 *Steven Folsom
>                 *Sent:* Monday, November 30, 2015 4:05 PM
>                 *To:* [log in to unmask]
>                 <mailto:[log in to unmask]>
>                 *Subject:* Re: [BIBFRAME] Categories proposal
>
>                 Joe,
>
>                 Not sure if you noticed, but it looks like LOC has
>                 published Carriers as bf:Carriers, see:
>                 http://id.loc.gov/vocabulary/carriers/sd.
>
>                 I haven’t fully formed my thoughts on the new
>                 Categories proposal, but I’ve been wondering… Can some
>                 or all the new bf:Carrier, bf:Content, bf:Media, and
>                 bf:GenreForm be handled by treating them as bf:Work
>                 and bf:Instance subclasses?
>
>                 Couldn’t/shouldn’t the new bf:hasContent be covered by
>                 part/whole Work relationships and bf:Work subclasses?
>
>                 Couldn’t/shouldn’t the new bf:hasCarrier be covered by
>                 bf:Instance subclasses?
>
>                 Example 1 would then look like:
>
>                 <ex:SomeWork> <bf:hasInstance>  <ex:SomeInstance> .
>
>                 <ex:SomeInstance> a <http://id.loc.gov/vocabulary
>                 <http://id.loc.gov/vocabulary/carriers/sd>/carriers/sd
>                 <http://id.loc.gov/vocabulary/carriers/sd> > .
>
>
>                 Based on what we’ve attempted to say about media in
>                 MARC (see,
>                 _http://www.loc.gov/marc/bibliographic/bd337.html)_,
>                 it seems like bf:hasMedia could also be covered by
>                 Work or Instance subclasses.
>
>                 If/when form and genre are decoupled, form types could
>                 then too be used as subclasses of Works or Instances.
>                 Genre is possibly the one hold-out. For example, a
>                 movie isn’t science fiction, but rather it has a genre
>                 of science fiction.  Instead of having science fiction
>                 as a subtype of work, we would need a bf:hasGenre
>                 property.
>
>                 Example 4 would then possibly look like:
>
>                 <ex:SomeWork> a <bf:Text> ;
>
>                   <bf:hasGenre>
>                 <http://id.loc.gov/authorities/subjects/sh99001678
>                 <http://id.loc.gov/authorities/subjects/sh99001678.skos.rdf%3e>>
>                 .
>
>                 Reactions? Rotten Tomatoes?
>
>                 Thanks,
>
>                 Steven
>
>                 ————
>
>                 Steven Folsom
>
>                 Metadata Strategist and Standards Advocate
>
>                 Cornell University Library
>
>                 *From: *Bibliographic Framework Transition Initiative
>                 Forum <[log in to unmask]
>                 <mailto:[log in to unmask]>> on behalf of
>                 Joseph Kiegel <[log in to unmask] <mailto:[log in to unmask]>>
>                 *Reply-To: *Bibliographic Framework Transition
>                 Initiative Forum <[log in to unmask]
>                 <mailto:[log in to unmask]>>
>                 *Date: *Monday, November 30, 2015 at 1:15 PM
>                 *To: *"[log in to unmask]
>                 <mailto:[log in to unmask]>"
>                 <[log in to unmask]
>                 <mailto:[log in to unmask]>>
>                 *Subject: *[BIBFRAME] Categories proposal
>
>                     In the Categories proposal, when the carrier
>                     (etc.) is asserted as a resource, additional
>                     assertions are made about that resource.  This is
>                     shown in example 1, where we see:
>
>                     <http://id.loc.gov/vocabulary/carriers/sd>
>
>                     a bf:Carrier
>
>                     rdfs:label “audio disc”
>
>                     This is an excellent opportunity to simplify by
>                     incorporating this type of assertion into the
>                     carrier, content, media and genre schemes
>                     themselves, in particular since they are
>                     maintained by LC.  This would spare libraries the
>                     work of making such assertions for each Instance,
>                     and reduce the clutter of identical assertions on
>                     a lot of different servers.
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600