 |
 |
It is a bit hard to explain how an abstract manifestation can have an extent. And where would you put extent when describing a unique item? Obviously on the item. Extent on manifestation is a convenience for describing all of the instances of a publication or production run. "Manifestation" could be "product description", and would not be included for unique items. I believe that FRBRoo makes this distinction better, but it is also much more complex. kc On 11/18/15 7:53 AM, Steven Folsom wrote: > 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] <mailto:[log in to unmask]>> on > behalf of "Young,Jeff (OR)" <[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, November 18, 2015 at 10:28 AM > To: "[log in to unmask] <mailto:[log in to unmask]>" > <[log in to unmask] <mailto:[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] <mailto:[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] > <mailto:[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] <mailto:[log in to unmask]>> > on behalf of Gordon Dunsire <[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, November 18, 2015 at 6:40 AM > *To:*"[log in to unmask] > <mailto:[log in to unmask]>" <[log in to unmask] > <mailto:[log in to unmask]>> > *Subject:*Re: [BIBFRAME] Properties of Item proposal > > Karen and others > > <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. > > <http://rdaregistry.info/Elements/e/P20003 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_e_P20003&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=uQXZeWRUjobV9dpubys5KvvOk2d5rIVp0K4DPD2I0Fs&e=>> > reg:lexicalAlias > <http://rdaregistry.info/Elements/e/otherDistinguishingCharacteristicOfTheExpression.en > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_e_otherDistinguishingCharacteristicOfTheExpression.en&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=KLKthPwPYscCA1ttgJ44bOupnCC2erRVdyX40g7aEFA&e=>> > . > > 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.: > > <http://digital.nls.uk/78693432 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__digital.nls.uk_78693432&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=gwTdb97bOEhwgyY92A_qYXCwZnWFr-e6JJCS6hDZKuY&e=>> > <http://rdaregistry.info/Elements/m/P30154 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_m_P30154&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=hVrrUTKHYsiN0qdTx5XJ53s33l7uTeHKHMxuhlKdklE&e=>> > "http://digital.nls.uk/rlstevenson/browse/pageturner.cfm?id=78693432 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__digital.nls.uk_rlstevenson_browse_pageturner.cfm-3Fid-3D78693432&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=ToXMkFMKfI03GSWT-upoU0WlJoNTT6n25uosbFL1Omw&e=>" > . > > 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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__digital.nls.uk_78693516&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=7E3bo-S145t45afqm9K7f6bGYvZbd135IpG4oVKcmmQ&e=>>. > > 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: > > <http://rdaregistry.info/Elements/m/P30154 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_m_P30154&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=hVrrUTKHYsiN0qdTx5XJ53s33l7uTeHKHMxuhlKdklE&e=>> > > a rdf:Property ; > > rdfs:domain <http://rdaregistry.info/Elements/c/C10007 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_c_C10007&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=lue5wJNbmdK6QW7LhO4mPD61UTEZEyVHhJzLtSzoWFI&e=>> > ; > > skos:definition "Relates a manifestation to the address of > a remote access resource."@en > <mailto:%22Relates%20a%20manifestation%20to%20the%20address%20of%20a%20remote%20access%20resource.%[email protected]> > . > > 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] > <mailto:[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] > <mailto:[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] > <mailto:[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 theWHATWG > <https://urldefense.proofpoint.com/v2/url?u=https-3A__whatwg.org_&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=TM5IhWBVww9Np2U8WFXtuhAw8WFwaWiwd50ijHZ0R_Y&e=>proposes > to do, standardizeURL > <https://urldefense.proofpoint.com/v2/url?u=https-3A__url.spec.whatwg.org_&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=ghmP71XZ69-NLyX4u_QnjRQgHxIPWDgXRHvzRlo_SpE&e=>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] > <mailto:[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; > seehttp://www.rda-jsc.org/sites/all/files/6JSC-TechnicalWG-6.pdf > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rda-2Djsc.org_sites_all_files_6JSC-2DTechnicalWG-2D6.pdf&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=b9VjLU8LrIX5AGFC1pV7IUcf883GdNCrnESWFPFVirA&e=>(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] > <mailto:[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] > <mailto:[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] > <mailto:[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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=>> > > Where again I am using turtle notation and I am > explicitly enclosing http://someURI > <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=> > in angle braces. I claim thathttp://someURI > <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=>(enclosed > in angle braces) must be dereferenceable as RDF > (meaning that there is an RDF representation of > that resource,http://someURI > <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=>, > 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] > <mailto:[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. > > Yourhttp://hdl.loc.gov/loc.pnp/cph.3g11323 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=60Np5o5w2LNBrurCRpmrvm8WzhaZVENoi-sbuUH-VJ0&e=>, > 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” > <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=>] > ; > > I maintain that it would be incorrect to instead say: > > bf:electronicLocator > <http://hdl.loc.gov/loc.pnp/cph.3g11323” > <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=>> > > because that would imply that you can retrieve RDF > by > dereferencinghttp://hdl.loc.gov/loc.pnp/cph.3g11323 <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=60Np5o5w2LNBrurCRpmrvm8WzhaZVENoi-sbuUH-VJ0&e=>, > 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] > <mailto:[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 > ishttp://hdl.loc.gov/loc.pnp/cph.3g11323 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=60Np5o5w2LNBrurCRpmrvm8WzhaZVENoi-sbuUH-VJ0&e=>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 aUnified Resource Identifier (URI) > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_2013_NOTE-2Dld-2Dglossary-2D20130627_-23uniform-2Dresource-2Didentifier&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=pJxh8Ddk2IAmQsrxpT17T2LYGVGoMqopZpI3Bzk280I&e=>." > [1] > > "AnyIRI > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23dfn-2Diri&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=-WsiTeyEcKqj9rQjv5n-jdjCcxJYFZacGcgxMt1N_pc&e=>orliteral > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23dfn-2Dliteral&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=XHJdSFgGL3kAk3ooq000N_Gqvr-95gXTW_9NILEslgw&e=>*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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23bib-2DRDF11-2DMT&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=Huj7eJIqck1aGkwaZYluHByn0km_fkWrFuUBWwjMo9k&e=>]."[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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_2013_NOTE-2Dld-2Dglossary-2D20130627_-23resource&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=vkTyy9_pYDC52FSwlUT-Sl9Yjq41Q2pZwgGy0hjr07I&e=> > [2]http://www.w3.org/TR/rdf11-concepts/#resources-and-statements > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23resources-2Dand-2Dstatements&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xxtN1uLkUFzmqhBCzxKrkeO5d7aWXyP5RhU9R-odIfQ&e=> > [3]http://www.w3.org/TR/rdf11-primer/ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dprimer_&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=tE8IeGbnF-ks7ZXWR46fW4i18zlssXoseqppMNKonKM&e=> > > If bf:electronicLocator were to be redefined as an > object property, then instead of this: > > <http://bibframe.example.org/item/item5> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.example.org_item_item5&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=YS_oDur7NszjtGPy18vd2nAFa1F76tNsSg2O3-90teE&e=> > > > a bf:Item ; > > bf:electronicLocator > “http://hdl.loc.gov/loc.pnp/cph.3g11323” > <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=> > ; > > …… > > It might look like this: > > <http://bibframe.example.org/item/item5> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.example.org_item_item5&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=YS_oDur7NszjtGPy18vd2nAFa1F76tNsSg2O3-90teE&e=> > > > a bf:Item ; > > bf:electronicLocator [ > > a bf:ElectronicLocator ; > > rdf:value > “http://hdl.loc.gov/loc.pnp/cph.3g11323” > <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=>] > ; > > …… > > 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] > <mailto:[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] <mailto:[log in to unmask]> http://kcoyle.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=3D7J3INr3nKlknCbiQK-C28KZMnM0j9zPDwzxFo4lnc&e=> > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 > > -- > > Karen Coyle > > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=3D7J3INr3nKlknCbiQK-C28KZMnM0j9zPDwzxFo4lnc&e=> > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 > > > > > -- > > Karen Coyle > > [log in to unmask] <mailto:[log in to unmask]> > http://kcoyle.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=3D7J3INr3nKlknCbiQK-C28KZMnM0j9zPDwzxFo4lnc&e=> > > 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