Print

Print


I've always interpreted the Manifestation to be the abstract "version" of the Work/Expression where we record traits related to that version, e.g. eBook Manifestation has an extent of 325MB, or the print Manifestation has 423 pages. The Item is the physical embodiment of Manifestation that can be found somewhere. 

For example, Amazon offers different Manifestations of a Work/Expression, but it’s Items located in their warehouse that the will ship to you. The same goes for Libraries, we have holdings of Manifestions, but it’s the Items that have locations and circulate.


From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of "Young,Jeff (OR)" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Wednesday, November 18, 2015 at 10:28 AM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Properties of Item proposal

Bruce,

 

I said something about solidity and *items* earlier. Is that what you’re remembering?

 

(To be clear, I didn’t say that items had to be solid, but some people have heard it that way.)

 

Jeff

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Gordon, Bruce J.
Sent: Wednesday, November 18, 2015 10:19 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Properties of Item proposal

 

Hold on. We were just told that manifestations were solid things. Which is it?

 

-Bruce

 

Bruce J. Gordon

Audio Engineer

Audio Preservation Services - a shared service of the Harvard Library

Harvard University

Cambridge, Massachusetts 02138

U.S.A

tel. +1(617) 495-1241

fax +1(617) 496-4636

 

On Nov 18, 2015, at 10:01 AM, Steven Folsom <[log in to unmask]> wrote:

 

Gordon,

 

I don’t think Karen is suggesting to derive meaning strictly from the name or labels of the property. She said the meaning comes from the semantics. 

 

In my limited experience, as humans we come to understand the semantics through axioms and annotations in the ontology, and… honestly when the axioms and annotations are not not enough we have to go to the property or class names, documentation and examples to try to understand "the meaning". [As an aside, there are ontology matching tools that recognize this, and (along with other techniques) they analyze the lexicalization of the names as part of their algorithms to align classes and properties between ontologies.]

 

The criticism with <rdam:P30154> is that the semantics of the property (come to be understood through the lexical aliases and skos:description) are for a relationship AND what seems to be the expected range, e.g. Has remote access + range of URL. The skos:definition "Relates a manifestation to the address of a remote access resource.” and the fact that the range is actually undefined seems suggest something different from the lexical aliases. One could get remote access to a resource through a phone call, so is a telephone number a valid object of the <rdam:P30154> property? 

 

I know Karen is advocating below for a more general rdax:location property, but maybe in this case we would want a more general rdax:access relationship that represents access to the resource. The object (in this scenario, a point of access) can be described through additional assertions about the point of access, whether it be a website, library, etc. The website and libraries can have a locations.

 

I’m not a RDA/FRBR expert, so I wondering what it means for a Manifestation to have a location at all. My sense is that Manifestations are still conceptual entities, and it would be Items that have locations. 

 

respectfully,

Steven

 

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Gordon Dunsire <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Wednesday, November 18, 2015 at 6:40 AM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Properties of Item proposal

 

 

<rdam:uniformResourceLocator.en> is a URI, as the angle-brackets indicate.

 

Actually, it's an RDA lexical alias that points to the canonical URI <rdam:P30154>. Lexical aliases are intended to give programmers some mnemonic support by reflecting the lexical label of the property in the "URI". Other lexical aliases for this URI are <rdam:uniformResourceLocator.de>, <rdam:localizadorUniformeDeRecurso.es>, and <rdam:adresseURL.fr> (awaiting activation). This human-readability comes at the cost of duplicating lexical aliases to preserve the mnemonic function if the property label changes, or perceptual semantic drift from the mismatch of alias and label.

 

This is a main reason why it is good practice to avoid embedding human-readable strings in a URI: human language changes and "meanings" drift, but URIs should be consistent persistent global identifiers. A more fundamental reason is that RDF works by completely separating the machine-readable identifier from the human-readable string. RDF expects all of the human-readable data in a triple to be stored as an object literal. Everything else is a URI.

 

The value of RDF data lies in the machine-programmable semantics of ontological statements about a property or class, and the human-readable definitions and scope notes stored as the objects of dataset triples. Using labels to store "meaning" involves too many issues; e.g.

 

 

The RDA Registry English label for the URL property P30154 is "has Uniform Resource Locator"@en; there is a variant RDA Toolkit label "Uniform Resource Locator"@en, and an internal Registry label“"uniformResourceLocator"@en. These labels are currently translated into French, German, and Spanish in the Registry and Toolkit.

 

So a machine would "see", e.g.:

 

 

The URL string that is the object of this triple is clearly not intended to be permanent, and will return a 404 error when the publisher of this manifestation stops using a ColdFusion database server. The publisher recognizes this by providing a permanent URL that can be used as the canonical URI of the manifestation. Furthermore, the manifestation is currently embedded in a larger aggregate manifestation that can be accessed from this and every other "page" URL provided by the service. This URL moves the service to the first page of the manifestation described, but the last page is not recorded (in human or machine-readable form) so the manifestation segues into the next manifestation with URI <http://digital.nls.uk/78693516>.

 

I think it is better to leave this URL as a string in RDA data. I don't think RDA is overloading or masking the type of the value; isn’t that what Jeff is proposing?

 

The semantics of the value are made clear by the property:

 

a rdf:Property ;

The RDA instructions, given in my earlier post, do not burden the cataloguer with any of this. The RDA Steering Committee intends to develop the instructions to make explicit reference to recording URIs for RDF linked data, following recommendation 5 of the paper, but this will take account of the Nomen entity and the function of the URL as an identifier. None of the discussion so far compels me to suggest changing the RDA definition of the URL property.

 

As far as I know, none of I, my colleagues developing the RDA Toolkit and Registry, or the intended users of RDA, are in "the state of having a serious mental illness" or exhibiting "extremely foolish behaviour". Rather, it is our intention to avoid, not promote, "a state of wild or chaotic activity" :-)

 

Cheers

 

Gordon

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: 18 November 2015 05:37
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

I agree with Jeff. The semantics of the value should be made clear by the property, and not by overloading or masking the type of the value. 

I think the problem is in the property "<rdam:uniformResourceLocator.en>" It should be something more like "rdax:location" if that's what the value means. URL is a kind of thing, not a relationship between entities. "ex:hasURL" (if you want to make it into a verb) is essentially about the the lowest semantics I can imagine. We don't create properties like "ex:string", we create properties that say what the string is about, such as "dct:title" or "skos:label". URL should be the value, not the predicate.

And if the URL goes to a splash page, well, it goes to a splash page. In line with the conversation we've had with Ray, your metadata can't control what's on the other end, and catalogers are not omniscient nor can they see into the future. What if the URL after a while returns a 404? How can cataloging rules have any control over that? 

I don't think that linked data is going to be any more perfect than unlinked data has been. And I don't think that we should burden humans with decisions about things that are arbitrarily outside of their control. That way lies madness.

kc

On 11/17/15 5:54 PM, Jeff Young wrote:

I'd say put them all in angle brackets. The ones that "get it" will rise to the top. The others are easily sniffed for what they are.


On Nov 17, 2015, at 5:35 PM, Gordon Dunsire <[log in to unmask]
> wrote:

Ray, All

 

I agree; anyone can say anything about any thing. This is what RDA says:

 

"A Uniform Resource Locator, or URL, is the address of a remote access resource.

Uniform Resource Locators include all resource identifiers intended to provide online access to a resource using a standard Internet browser.

Take information on Uniform Resource Locators from any source.

Record the Uniform Resource Locator for the online resource being described.

If there is more than one Uniform Resource Locator for the resource, record one or more according to the policy of the agency preparing the description.

Record a Uniform Resource Locator for a related resource as part of the description of the related manifestation."

 

"Resource" here means the RDA/FRBR entity Manifestation, and nothing else.

 

In practice, the URL recorded may resolve to (get) an online file constituting the real-world object that is the resource being described, or it may resolve to a so-called jump-off page that links to various related versions/formats of the resource being described, or it may resolve to an interactive page such as a page-turner, and so on. All of these cases are covered by the instructions, but only the first case allows a semantically coherent and machine-readable resolution of the data. Thus I think that the RDA URL data is non-resolvable (not un-resolvable) in the context of a coherent linked data application. It is a similar case to other Manifestation identifiers, such as ISBN which cannot guarantee, in principle, that a single number/identifier refers to one and only one Manifestation.

 

I think it is important to make the distinction. If the RDA URL is treated as a URI, then what does the URI identify?

 

Suppose <resource1URI> <rdam:uniformResourceLocator.en> <URL1> .

 

If <resource1URI> and <URL1> are URIs for the same Manifestation, then <resource1URI> owl:sameAs <URL1> . This makes the URL property redundant.

 

If they are URIs for different Manifestations, then the RDA instructions are clear that the URL should not be recorded as a value of the URL property.

 

The RDA Steering Committee intends that the data produced using the RDA instructions and represented as linked data using the RDA element sets and value vocabularies are coherent. There is nothing in this approach that is inconsistent with RDF or FRBR.

 

Applications are free to interpret the value of RDA URL as a URI that resolves to a web document; the RDA property does not declare a range. That document might be the Manifestation/Item in focus, or a log-on form, or something else. Applications can also impose URI functionality on URLs declared as literals - but RDA data will not guarantee any consistency in the results.

 

This is the only reason I can come up with for an application needing to know the provenance, or anything else, of a URL in this context (was it the location of some other document in the past? is it the location of some other document now?). Using RDF means we don't have to talk about URIs as identifiers; the provenance of a URI is all the triples that use it.

 

The RDA approach is evolving to conform to the new consolidated FRBR model, which introduces the entity Nomen. We expect the range of an evolved sub-property of RDA URL (and many other elements such as titles of works and manifestations, names, access points, and other identifiers) to be declared as Nomen, allowing the provenance of any such identifying string to be recorded as linked data. The entity has similar semantics and functionality as skosxl:Label.

 

Cheers

 

Gordon

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Denenberg, Ray
Sent: 17 November 2015 20:20
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

Gordon – I suppose RDA is free to define URIs and URLs, and the distinction between them,  as it sees fit, since there are already a number of different views.  But in my opinion, to consider a URL to be a non-resolvable identifier is a serious mistake.

 

In my view (just one of many), there is no substantive difference.  Not that there is NO difference, but the difference is not worth the time to agonize over.  When I am discussing a link with someone unfamiliar in general with Web terminology, say,  a link on a web page, I use “URL”. If I say “URI” they have no idea what I’m talking about.  And the URL I’m discussing with that person is of course resolvable.  On the other hand, when discussing linked data, RDF, etc. I say “URI”; “URL” doesn’t seem to have much meaning in that context.

 

I recently wrote a brief primer on BIBFRAME RDF for LC catalogers.  Upon introducing the URI concept, I said:

“At this point, people usually ask what is the difference between a URI and URL.  For purposes of this discussion, there is no substantive difference whose explanation would be of any value, so assume they are the same.”  

Anyway, that’s how I see it.

 

And I’ll add that if one takes the view that they are substantially the same, it follows that it might be a good idea to standardize on one and drop the other.  And that’s what the WHATWG proposes to do, standardize URL and drop URI. Me, I prefer URI, but I won’t fight that battle.

 

Ray

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Gordon Dunsire
Sent: Tuesday, November 17, 2015 9:16 AM
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

All

 

The JSC Technical Working Group discussed the issue of URL vs URI in a paper discussed by the RDA Steering Committee a few days ago; see http://www.rda-jsc.org/sites/all/files/6JSC-TechnicalWG-6.pdf (page 4 and following). The RSC accepted recommendation 1 and is taking appropriate action.

 

The basic conclusion is that a URI is a thing (RDF resource), and a URL is a string (non-resolvable identifier). This is reflected, I think, in the basic syntax of RDF: a piece of data in quotes is a string (human-readable) and all other data in a triple are things (machine-readable URIs). Using angle-bracket and quote delimiters, the two basic triple syntaxes are:

 

<subjectURI> <propertyURI> <objectURI> .

<subjectURI> <propertyURI> “object string” .

 

I hope this paper is of use – and please let me know (as Chair of the Working Group) if you disagree with anything.

 

Cheers

 

Gordon

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Denenberg, Ray
Sent: 16 November 2015 22:19
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

Well of course.  You can never guarantee good behavior of an independent system.  I’m only saying that these are the rules we are supposed to be playing by.  If I encounter an object of a triple which looks like an RDF resource URI, I dereference it (requesting RDF), and you refuse the request, I’d consider that a failure.

 

Ray

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of LeVan,Ralph
Sent: Monday, November 16, 2015 4:58 PM
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

Ray, my VIAF server does provide RDF when asked via content negotiation.  Today it does.  So, today triples that have a VIAF URI in them are legal, but tomorrow when I break content negotiation they suddenly become illegal?  It’s impossible for the coiner of the triple to guarantee some third-party server behavior.  It’s up to the consumer of the triple to identify those URIs that are pointers to RDF and do whatever seems appropriate.

 

Ralph

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Denenberg, Ray
Sent: Monday, November 16, 2015 4:14 PM
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

Karen,  take this one step at a time.  Suppose I have a triple:

 

     <some subject>   bf:someProperty   <http://someURI>

 

Where again I am using turtle notation and I am explicitly enclosing   http://someURI  in angle braces.   I claim that http://someURI (enclosed in angle braces) must be dereferenceable as RDF (meaning that there is an RDF representation of that resource, http://someURI, which may be one of many representations, and I can get that RDF representation by doing a get on it requesting RDF via content negotiation).

 

Do you not agree?

 

 

(And you’re saying that “RDF resource” is defined in the documents you cited, but that expression doesn’t even occur in any of those documents.  Nowhere. So I’m confused.)

 

 

 

Ray

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Monday, November 16, 2015 3:44 PM
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

 

On 11/16/15 10:37 AM, Denenberg, Ray wrote:

Hi Karen – Yes there certainly is a terminology issue, particularly because the expression “RDF resource” does not have a formal definition, anywhere (that I have ever been able to find).


Actually, Ray, the quotes I gave you in my email are indeed the formal definition from the W3C specifications. There is probably an even more formal definition somewhere using virtually unreadable notation, but I think that what the human-readable documents say is quite clear -- which is that a resource is "anything that an RDF graph describes" and that it can be either an IRI or a literal. I agree with you that folks often refer to IRIs as resources as opposed to literals, but that's a misnomer. Another way of saying this is "string vs. thing" but there's probably some ambiguity in that as well. But most importantly, as I said below, nowhere have I encountered any statements that there is any distinction made that what one obtains upon dereferencing must be "RDF". In fact, I don't know what that actually means.

Your http://hdl.loc.gov/loc.pnp/cph.3g11323, which very clearly follows the rules for an IRI (and IRIs do not need to be dereferenceable) is an IRI. What it does or does not dereference to does not change that. You can treat an IRI as a literal string (I don't think there's anything in RDF to prevent that) -- and therefore indicate that you don't intend it to be actionable as an IRI. However, again, your distinction of "imply that you can retrieve RDF by dereferencing" is not familiar to me.

kc

However, whenever I encounter the expression it seems to be used in the sense that I’m using it.   Which is this:

In any RDF triple the object is a literal or an RDF resource.  A literal is of course a resource; and I am making a distinction between “resource” and “RDF resource”. 

So, the object of a triple is either:

1.       a literal, in which case it’s enclosed in quotes (assuming turtle serialization); or   

2.       not enclosed in quotes, in which case it is an RDF resource URI (either enclosed by curly braces or using namespace prefix notation), or a blank node id.   

 

For case 2, the URI can be dereferenced resulting in an RDF description or if it is a blank node it points to an RDF description.


Do you agree (so far)?  If you think I’m using the expression “RDF resource” incorrectly then what is your definition?  If you think “RDF resource” and “resource” mean the same thing, I disagree, but then, I could be wrong, since “RDF resource” has no formal definition.  But I’m using it in the sense that I see it used. 

 

Anyway, having said all that, getting back to the example at hand

 

      bf:electronicLocator  [

                 a    bf:ElectronicLocator ;

                  rdf:value   “http://hdl.loc.gov/loc.pnp/cph.3g11323” ] ;

 

I maintain that it would be incorrect to instead say:

 

bf:electronicLocator  <http://hdl.loc.gov/loc.pnp/cph.3g11323” >

 

because that would imply that you can retrieve RDF by dereferencing http://hdl.loc.gov/loc.pnp/cph.3g11323 , which (as far as I know) you can’t.

 

Ray

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Sunday, November 15, 2015 8:30 PM
To: [log in to unmask]

Subject: Re: [BIBFRAME] Properties of Item proposal

 

 

On 11/12/15 12:05 PM, Denenberg, Ray wrote:

Hi Joseph – thanks for the comments and questions.  I want to address two points, while we are still discussing the other suggestions.

 

bf:electronicLocator is, at present, conceived to be a datatype property; its expected value is a literal.  We could change that to an object property if that’s what people want, however, the URI would still be a literal, because it is not an RDF resource.   In the example, the electronic locator is http://hdl.loc.gov/loc.pnp/cph.3g11323 and this is not an RDF resource. (By RDF resource, we mean, you can dereference the URI and get RDF in response. You can’t for this URI.)


Ray, can you say more about this concept of a non-resource? AFAIK, many URIs do not dereference to  "RDF in response", but they are still considered resources in RDF. I'm looking at:

"90. Resource
In an RDF context, a resource can be anything that an RDF graph describes. A resource can be addressed by a Unified Resource Identifier (URI)." [1]

"Any IRI or literal denotes something in the world (the "universe of discourse"). These things are called resources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with "entity" as it is used in the RDF Semantics specification [RDF11-MT]."[2]

There is similar language in the RDF 1.1 primer. [3]

This might be a terminology issue, but even accepting a different terminology, I'm not aware of any distinction where a response to the dereferencing of an IRI must be RDF (meaning? ntriples? JSON-LD?) rather than any RDF:resource (e.g. a jpeg file, an html file, an avi file). 

kc
[1] http://www.w3.org/TR/2013/NOTE-ld-glossary-20130627/#resource
[2] http://www.w3.org/TR/rdf11-concepts/#resources-and-statements
[3] http://www.w3.org/TR/rdf11-primer/

If bf:electronicLocator were to be redefined as an object property, then instead of this:

 

          a                                        bf:Item ;

          bf:electronicLocator      “http://hdl.loc.gov/loc.pnp/cph.3g11323”  ;

……

 

It might look like this:

 

          a                                        bf:Item ;

          bf:electronicLocator  [

                                                   a    bf:ElectronicLocator ;

                                                    rdf:value   “http://hdl.loc.gov/loc.pnp/cph.3g11323” ] ;

      ……

 

Where here we now have defined class bf:ElectronicLocator, but the URI is still a literal.

 

 

Second, should bf:itemOf (property of item) have a reciprocal property, bf:hasItem (property of Instance).

I don’t know; opinions are welcomed on this question.  We did not include it in the draft for this reason: an item knows (or should know) what Instance it is an Item of.  An Instance in general does not know the existence of all items that claim to be an item of that Instance. So if there were to be a property bf:hasItem, it could be used within an Instance to point to all items that that Instance knows about with the disclaimer that it doesn’t claim to point to all its items. If, as such, this would be useful then we can add the property.  (The same dilemma applies to instanceOf and hasInstance. And granted, these are both included in BIBFRAME 1.0.)

 

Ray

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
Sent: Tuesday, November 10, 2015 1:39 PM
To: [log in to unmask]

Subject: [BIBFRAME] Properties of Item proposal

 

Items in BIBFRAME may serve different purposes, which is not addressed in the Items proposal.  A relatively narrow purpose is to support the user task obtain, while a more complex one is to support a working circulation system.  The properties elaborated in the proposal are not sufficient even for the user task obtain.  Here are comments on them.

 

bf:electronicLocator:  should the expected value be a URI?  It seems odd to express URLs as literals in linked data.

 

 

bf:heldBy and bf:subLocation:  the MARC holdings format and many library systems recognize three levels of location information: organization, library and sublocation within a library.  BIBFRAME should support the same number of levels:  for example, it should add a property such as bf:location, which is intermediate between bf:heldBy and bf:subLocation. 

 

bf:heldBy University of Washington Libraries

bf:location:  Art Library

bf:subLocation:  Reference stacks

 

bf:heldBy University of Washington Libraries

bf:location:  Engineering Library

bf:subLocation:  Reference stacks

 

Without bf:location, reference or general stacks locations in different buildings appear to be the same.

 

 

bf:itemOf:   is a reciprocal property needed?  For example, bf:hasItem, a property of bf:Instance with an expected value of bf:Item.

 

 

Two properties are lacking from the proposal:  bf:itemStatus and bf:circulationCharacteristic

 

bf:itemStatus:  it is crucial to inform users of the status of an item, e.g. available, checked out, missing, withdrawn, at the bindery, etc.

 

bf:circulationCharacteristic:  another important aspect of materials is the general policy that governs them, e.g. circulating or library use only.  It is tempting to try to include this characteristic in bf:itemStatus, but they are independent aspects.  LUO materials may be missing, at the bindery or even checked out (e.g. faculty loans of reference materials). 

 

 

 

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

 

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




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