LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  June 2016

BIBFRAME June 2016

Subject:

Re: FW: [BIBFRAME] rdf:value

From:

Stuart Yeates <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Wed, 29 Jun 2016 20:27:25 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (400 lines)

> Then the question is always: Well, what if we have to add a term? Answer: it's no harder to add a new
> predicate than it is to add a new member of a list - both need URIs, both need to be documented, both
> need to be shared.

This does not appear to be true in the manner in which is was meant.

Adding a predicate to a vocabulary requires minting a new vocabulary (maybe by incrementing a counter in the name and url of an existing vocabulary). Due to the complexities of mapping between vocabularies in the general case, communicating ecosystems of information systems (think library consortia and the ilk) will require a uniform vocabulary versions. So library consortia will need consortia-wide coordination to introduce new predicates.

Adding a term to a list involves minting a new URL. Assuming the existence of sane networking infrastructure (IPv4 or IPv6, DNS, etc),  the rest of the consortia doesn't need to know about the URL, it should just resolve to something sane when people dereference it.

cheers
stuart

--
I have a new phone number: 04 463 5692
https://www.facebook.com/VUWLibrary / https://www.facebook.com/TKMPC

________________________________________
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Karen Coyle <[log in to unmask]>
Sent: Wednesday, 29 June 2016 9:39:09 a.m.
To: [log in to unmask]
Subject: Re: [BIBFRAME] FW: [BIBFRAME] rdf:value

Here's my interpretation of what the reality is behind "what people say" in terms of not wanting a proliferation of predicates. They are thinking of a monolithic vocabulary (cf MARC, LCC, RDA) that is extant as a single, huge document. It's very complex. Pages and pages of stuff to leaf through. Some of the complexity has been taken out of the document by creating side lists -- lists of types, genres, organizations... All of these are data elements, but they are "out of sight" because they are separate lists. And to many people this has "simplified" the vocabulary, putting these outside of the main document.

Now, just because something is of your vocabulary it doesn't mean that it has to be documented in one huge document. You could take a group of predicates that represent ID types or genres and place them in a separate human-readable document even though they are truly members of your vocabulary. There's really no difference in terms of complexity between a list of 200 genre terms and 200 predicates representing those same terms. And you can treat the predicates as subclasses of a class if that works for you (class-ness can also be ignored if one wants). But don't pretend that one is "more complex" than the other. 200 terms are 200 terms.

Then the question is always: Well, what if we have to add a term? Answer: it's no harder to add a new predicate than it is to add a new member of a list - both need URIs, both need to be documented, both need to be shared.

I think we need to get over this fear of "too many predicates". Note that using predicates rather than term types would actually simplify the data generated because we'd have fewer non-sharable blank nodes. It's just better.

kc

On 6/25/16 7:02 PM, Young,Jeff (OR) wrote:
Karen,

Machines are good a dumbing down vocabulary based on rules. Human understanding doesn't scale in reverse. RDF statements aren't exactly sentences, but there are enough people with in-between understanding now. We need to start taking advantage of it.

Jeff

On Jun 25, 2016, at 9:54 PM, Karen Coyle <<mailto:[log in to unmask]>[log in to unmask]<mailto:[log in to unmask]>> wrote:


Jeff, I absolutely agree, although one always hears complaints about the "proliferation of predicates." The advantage (?) of data types is that you have one predicate and the types can be ignored by those who just don't care what exact type of thing it is. Another option is to define predicates for the major identifiers (we know what they are) and use types (or blank nodes) for the remainder. I don't understand the logic that if some elements need extra complexity, it's a good idea to impose that complexity everywhere.

kc

On 6/25/16 3:49 PM, Jeff Young wrote:
It could also be expressed as:
X ex:isbn “9783110413014” .
That wouldn't require any new data types. It would only require defining ex:isbn as a property, which seem more in keeping with the spirit of RDF.

On Jun 25, 2016, at 6:36 PM, Karen Coyle <<mailto:[log in to unmask]>[log in to unmask]<mailto:[log in to unmask]>> wrote:


[Note: resending after 2 days because it hasn't appeared on the list.]


There appears to be no limitation on the creation of types in RDF. RDF incorporates the XML types as a convenience, but the specification[1] says:

" Any datatype definition that conforms to this abstraction may be used in RDF, even if not defined in terms of XML Schema."

"A datatype consists of a lexical space<https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-lexical-space>, a value space<https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-value-space> and a lexical-to-value mapping<https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-lexical-to-value-mapping>, and is denoted by one or more IRIs<https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-iri>."

The document at https://www.w3.org/TR/swbp-xsch-datatypes/ describes how user-defined datatypes can be defined and used. Use of datatypes could obviate the need for blank nodes, such that this:

      bf:identifiedBy    [  a    bf:Isbn
                            rdf:value   “9783110413014”   ] .
Could be expressed as
X bf:identifiedBy “9783110413014” ^^ex:isbn .
-kc


[1] https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-Datatypes

On 6/20/16 3:49 PM, Tom Johnson wrote:
On Mon, Jun 20, 2016 at 3:01 PM, Fallgren, Nancy (NIH/NLM) [E] <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Agreed that a string is a datatype and that it is the default when no specific datatype is declared; however,  I don’t tend to think of a string as a structured value or at least as something that a machine would understand as a structured value (but it’s certainly possible that’s a misunderstanding on my part).  For example, a machine looking at an ISBN as just some string would not understand that the numeric sequence actually has significance.

The structure, in this case, is captured by other properties of the resource (in existing examples, primarily the type). As a hypothetical, consider an ISBN node like:

   :work bf:identifier [ a bf:isbn ;
                         rdf:value    "9783110413014" ;
                         ex:isbnEAN   "978" ;
                         ex:isbnGrp   "31" ;
                         ex:isbnPub   "1041" ;
                         ex:isbnTitle "301" ;
                         ex:isbnXdig  "4" ] .

Would you agree that this is an example of structured data? This seems to me to be the kind of thing the RDF Primer is discussing.

Of course, an actual ISBN datatype definition would obviate the need for any of this (arguably including the blank node bf:isbn instance). I'm not sure whether I would advocate defining a suite of identifier datatypes; the current strategy seems more flexible.

With apologies if I’m being obtuse and belaboring this, but “Use rdf:value and rdfs:label as appropriate” doesn’t help me understand how they are each applied.  Perhaps the original question should be restated specific to the BF 2.0 Item example –
In the Item example below, what is the difference that causes the strings “unrestricted” and “LB 2395 . . .” to be asserted as rdf:value, while “available” is asserted as an rdfs:label?  All three are human readable strings, one is an alphanumeric assembled from a standard with rules, the other two are common terminology (from a standard vocab somewhere that is not published as RDF?), none of them name a resource, all describe attributes of the resource (circulation status, accessibility, and shelf location) – what criteria determine whether they are rdf:value or rdfs:label?  In BF 2.0, what constitutes appropriate application of rdf:value and rdfs:label to this data?

<<http://bibframe.example.org/item/itemZ>http://bibframe.example.org/item/itemZ >
a              bf:Item ;
bf:heldBy            [rdfs:label “Library of Congress” ] ;
bf:subLocation  [rdfs:label “Prints and Photographs Division” ] ;
bf:physicalLocation [rdfs:label “Reference collection” ] ;
bf:itemOf http://bibframe.example.org/instance/instanceY ;
bf:shelfMarkLcc [rdf:value “LB2395.C65 1991” ] ;
bf:usageAndAccessPolicy [
a bf:AccessPolicy ;
rdf:value “unrestricted” ] ;
bf:status              [rdfs:label “available” ] ;
bf:note                 [rdfs:label “Page 31 torn” ] .

Thanks,
Nancy



From: Denenberg, Ray [mailto:[log in to unmask]<mailto:[log in to unmask]>]
Sent: Monday, June 20, 2016 4:57 PM

To: <mailto:[log in to unmask]> [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] FW: [BIBFRAME] rdf:value

Hi Tom –

Yes, my wording regarding rdfs:literal was a bit lazy. Actually rdfs:literal is defined, it is a class, the class of all literal values and the value of rdf:value is a member of this class, meaning the range of rdf:value is rdfs:literal (although I can’t find anywhere in the specs that actually says this) so it is a class/range rather than datatype. It seemed easier to just say the rdf:value datatype is rdfs:literal.  But you’re right, technically that’s incorrect.

On the conventions document questions.

Second point.   What the second point tries to say is this. Nothing terribly profound, but say you want to express that an instance has carrier “audio disc”. Then any of the following three way is acceptable:

                    bf:carrier               <<http://id.loc.gov/vocabulary/carriers/sd>http://id.loc.gov/vocabulary/carriers/sd>  .




bf:carrier                     <<http://id.loc.gov/vocabulary/carriers/sd>http://id.loc.gov/vocabulary/carriers/sd>     .

<<http://id.loc.gov/vocabulary/carriers/sd>http://id.loc.gov/vocabulary/carriers/sd>
                      a bf:Carrier ;
                     rdfs:label “audio disc” .



bf:carrier <<http://id.loc.gov/vocabulary/carriers/sd>http://id.loc.gov/vocabulary/carriers/sd>   [
                      a bf:Carrier ;
                     rdfs:label “audio disc” ] .



URI vs. Blank Node.  Again nothing profound. Just that specifying whether it is acceptable to create blank nodes vs. requiring that a URI must always instead be created is outside the scope of an ontology.

Inverse property . Yes, we meant inverse, not reciprocal.  When would an inverse property be appropriate or inappropriate?  I cannot really articulate a firm rule,.  In some cases it’s clear: instance and instanceOf.  In some cases less clear: subject. BIBFRAME has defined a number of  inverse properties and will continue to do so when a clear need is indicated.  BIBFRAME’s position though is to not simply declare an inverse for every property just in case it happens to be needed some day.

Datatype vs. Object Properties.  There was much discussion of this, on this listserv (quite a while back) and there was a strong consensus that there be no property that could take a literal object in one statement and a resource in another. Thus every property should be declared be a datatype or object property and BIBFRAME has explicitly done so, via OWL.

Classes and types.  Do we mean the same thing?  Yes and no.  This is a guideline used in the development of the ontology.  Take identifier types, for example.  In BF 1 The type of identifier was expressed via property (e.g. bf:isbn).  In BF2 it is expressed via class (bf:Isbn).   So in BF 2, yes, type is intended to mean class membership.  (There are a few exceptions,  a few type properties to be used when there is no known class and the type must be expressed as a string, for example note type).

Proliferation of properties.  There were cases in BIBFRAME 1 of multiple properties that have been consolidated into a single property in BIBFRAME 2. For example there was classificationScheme and identiferType and these have been consolidated into the single property bf:source (a literal, used only when there is no known class) because it would only occur within a bf:Classification or bf:Identifier resource (respectively) so it would be known whether it is a classification or identifier source.

rdf:value vs. rdfs:resource.  Which says “Use rdf:value and rdfs:label as appropriate when supplying the value of a resource” probably should be truncated to “Use rdf:value and rdfs:label as appropriate”. Either that or elaborate as discussed in this thread,

Thanks, hope that helps, and keep those questions coming!

Ray


From: Bibliographic Framework Transition Initiative Forum [<mailto:[log in to unmask]>mailto:[log in to unmask]] On Behalf Of Tom Johnson
Sent: Monday, June 20, 2016 3:44 PM
To: <mailto:[log in to unmask]> <mailto:[log in to unmask]> [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] FW: [BIBFRAME] rdf:value

Chiming in to agree with Ray that, in general, xsd:string is an appropriate datatype for an rdf:value. And that ISBNs, in particular, are not xsd:integers. Their value space is not aligned with that type (as defined at [0].

Note that all literals have datatypes (see [1]). As a minor correction to Ray's point, the default datatype for for concrete syntaxes supporting "simple literals" is xsd:String, rather than rdfs:literal (which is not defined).

I don't think it's correct that rdf:value is an alternative to a URI. Indeed, it may often be useful to assign URIs to resources with declared values (e.g. to enumerate values for later use). Apart from that, I agree with where the group has landed on the differences from label types: labels name resources, while values express, to some extent, /what the resource is/.

To bring us back to the original issue: I recently read the conventions document, and found that I couldn't understand many of the items there. Perhaps some examples and/or motivations should be given?

Specifically, I could use clarification on:

  (2) What is meant by this? does it say more than simply "use RDF"? Is it advising that data publishers avoid blank nodes without labels?
  (3) What is the issue of URI vs. blank node? What does it mean to have no position? The explanation of this item seems to misunderstand blank nodes.
  (5) Does this mean to say "inverse property", rather than reciprocal? When might a such a property be appropriate or inappropriate?

I have smaller concerns about:

  (1) Can a reason for this decision be given? Is the goal to leave the door open for OWL-DL?
  (4) This one has a good explanation, but some loose use of language; (e.g.  "Some advantages of representing type as class rather than property"). Additionally, is "type" intended to mean something more specific than class membership?
  (7) Are there examples? I think I understand this to be avoiding properties like :isPartOfWork, :isPartOfInstance, etc..., but I'm mostly guessing.
  (8) (As discussed in this thread).

- Tom

[0] <https://www.w3.org/TR/xmlschema-2/#integer> https://www.w3.org/TR/xmlschema-2/#integer
[1] https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal



On Mon, Jun 20, 2016 at 11:45 AM, Denenberg, Ray <<mailto:[log in to unmask]>[log in to unmask]<mailto:[log in to unmask]>> wrote:
Values of rdf:value in BIBFRAME do have a datatype:  rdfs:literal.  That means that unless declared otherwise, it is a string by default. Whenever you want, you can refine a literal
e.g.
(1) rdf: value  “10”
(2) rdf:value  “10”^^xs:int

The first is a string; the second is an integer.  But there is nowhere in BIBFRAME that you would refine a value of rdf:value.


Consider for example a bf:Identifier. BIBFRAME prescribes that you assert the value of the identifier by rdf:value:

       bf:identifiedBy    [  a                             bf:Isbn
                                      rdf:value                 “9783110413014”   ] .


“9783110413014”  is a string.  You could refine it and assert that it’s an integer:

                         rdf:value “9783110413014”^^xs:int

But you don’t want to do that because it isn’t an integer, it’s just a string.    And wherever rdf:value is prescribed in BIBFRAME, it is just a string.

Someday you may be able to assert that it has datatype “isbn”….

                         rdf:value “9783110413014”^^xyz:isbn

… and that may facilitate processing of the isbn string.  But there is no such primitive datatype yet. However the statement “a bf:Isbn” would seem to serve that purpose.

My point being that wherever rdf:value occurs, though there may not be an explicit primitive datatype, the actual datatype is understood by context.


There are datatype properties in BIBFRAME where is makes sense to refine the datatype.  Take bf:count or bf:date for example
Someone might declare:
          bf:count   “10”
and someone else declare:
      bf:count   “10”^^xs:int

Or
            bf:date “June 20, 2016”
vs:      bf:date “20160620”^^xdt:date

And in both cases the second form is going to be more easily processed.

But neither of these is supplied via rdf:value; they are datatype properties, for which rdf:value doesn’t apply.

Ray





From: Bibliographic Framework Transition Initiative Forum [mailto:<mailto:[log in to unmask]>[log in to unmask]<mailto:[log in to unmask]>] On Behalf Of Joseph Kiegel
Sent: Monday, June 20, 2016 1:18 PM

To: <mailto:[log in to unmask]> <mailto:[log in to unmask]> [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] FW: [BIBFRAME] rdf:value

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>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]>mailto:[log in to unmask]] On Behalf Of Fallgren, Nancy (NIH/NLM) [E]
Sent: Monday, June 20, 2016 9:24 AM
To: <mailto:[log in to unmask]> <mailto:[log in to unmask]> [log in to unmask]<mailto:[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> <https://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue> 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

Nancy J. Fallgren
Metadata Specialist Librarian
Cataloging and Metadata Management Section
Technical Services Division
National Library of Medicine
<mailto:[log in to unmask]>[log in to unmask]<mailto:[log in to unmask]>



From: Hubay Miklós [<mailto:[log in to unmask]>mailto:[log in to unmask]]
Sent: Monday, June 20, 2016 11:46 AM
To: <mailto:[log in to unmask]> <mailto:[log in to unmask]> [log in to unmask]<mailto:[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."

<https://www.w3.org/TR/rdf-schema/>https://www.w3.org/TR/rdf-schema/

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' <mailto:[log in to unmask]> <mailto:[log in to unmask]> <[log in to unmask]><mailto:[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]>mailto:[log in to unmask]] On Behalf Of Robert Sanderson
Sent: Monday, June 20, 2016 8:26 AM
To: <mailto:[log in to unmask]> <mailto:[log in to unmask]> [log in to unmask]<mailto:[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 <<mailto:[log in to unmask]>[log in to unmask]<mailto:[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...



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



Item
Example (truncated)
<http://bibframe.example.org/item/itemZ>
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.

HTH,

Rob

--
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 Gyor, Egyetem tér 1.

Tel.: 96/613-443

email: [log in to unmask]<mailto:[log in to unmask]>




--
Karen Coyle
[log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net
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
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
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager