I agree.


It seems that the object of rdf:value should have a datatype.  A good basis for a list of datatypes is the table in RDF Semantics (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#DTYPEINTERP).  These types are widely understood.  Of course, local types can be established but they make widespread sharing of data more difficult.


Looked at from this point of view, only one case from the examples of rdf:value in the BIBFRAME specifications fits an xsd datatype:  ISBNs are integers.  The rest do not conform to a standard datatype.



From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Fallgren, Nancy (NIH/NLM) [E]
Sent: Monday, June 20, 2016 9:24 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] FW: [BIBFRAME] rdf:value


At NLM, we’ve been asking the same question as Joe in re use of rdf:value v. rdfs:label in the BF 2.0 Item examples.  The use of rdf:value with a text string or with common terminology for which there should probably be a URI doesn’t make sense to us either. 


It’s pretty clear that W3C defines rdf:value as a ‘structured’ value while rdfs:label is for a human readable label.   But the W3C definition of rdf:value as an idiom with no meaning on its own, seems to indicate that it needs to be used within some context.  The W3C example in the Primer https://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue implies that it should have a datatype (which makes sense for a machine to understand a structured value) as well as another property giving context about the structured value.  So, if LC shelf mark has a structured/standard datatype that can be interpreted by machines as an LC Shelf mark, then use of rdf:value could make sense in that context; otherwise, it seems rdfs:label would be preferable.


Also, best practices for sharing LD should probably not entail local interpretation of properties from another vocabulary.   




Nancy J. Fallgren

Metadata Specialist Librarian

Cataloging and Metadata Management Section

Technical Services Division

National Library of Medicine

[log in to unmask]




From: Hubay Miklós [mailto:[log in to unmask]]
Sent: Monday, June 20, 2016 11:46 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] FW: [BIBFRAME] rdf:value


Imho, the two properties are different. One is for value-declaration, and the other one is "may be used to provide a human-readable version of a resource's name."


2016.06.20. 17:34 keltezéssel, Joseph Kiegel írta:

Sorry, I meant rdfs:label.


From: Joseph Kiegel
Sent: Monday, June 20, 2016 8:34 AM
To: 'Bibliographic Framework Transition Initiative Forum' <[log in to unmask]>
Subject: RE: [BIBFRAME] rdf:value


So is rdfs:value.  The question is:  what is the “appropriate” difference between the two?



From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
Sent: Monday, June 20, 2016 8:26 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] rdf:value


It's the value of the resource to which it's attached.


On Mon, Jun 20, 2016 at 5:18 PM, Joseph Kiegel <[log in to unmask]> wrote:


bf:identifiedBy [ a bf:Isbn

rdf:value “9783110413014” ] .

Example 2

bf:identifiedBy [ a identifier:ABC ;

rdf:value “MX3-387” ] .

Example 3

bf:identifiedBy [ a bf:Identifier ;

bf:source “xyz” ;

rdf:value “1234567890” ] .


There is an ISBN, and its value is 9783...

There is an ABC identifier, and its value is MX3-387

There is an untyped identifier from source system xyz, and it's value is 123...





Example 3

bf:baseMaterial [

bf:code [ rdf:value “o” ;

bf:source [rdf:value “marc007ng04” ] ] ;

bf:note [ a bf:Note ;

rdfs:label “Image printed on thick gold paper.” ] ] .


There is an untyped resource, which one imagines is a Code, with value "o".

There is an untyped resource, which is some sort of Source, with value "marc007..."





Example (truncated)


bf:shelfMarkLcc [rdf:value “LB2395.C65 1991” ] ;

bf:usageAndAccessPolicy [

a bf:AccessPolicy ;

rdf:value “unrestricted” ] .


There is an LCC, and its value is LB...

There is a Policy and its value is "unrestricted"   

Note -- this use is not very machine friendly. A better model would have identifiable policies, with their own URIs.







Rob Sanderson

Semantic Architect

The Getty Trust

Los Angeles, CA 90049

Hubay Miklós
tájékoztató könyvtáros, könyvtárirendszer-adminisztrátor, MTMT-adminisztrátor
Széchenyi István Egyetem Egyetemi Könyvtár
9026 Győr, Egyetem tér 1.
Tel.: 96/613-443
email: [log in to unmask]