LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  July 2014

BIBFRAME July 2014

Subject:

Re: BibFrame and Linked Data: Identifiers

From:

Thomas Berger <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Thu, 17 Jul 2014 12:43:44 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (191 lines)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The message quoted below was sent to my private adress rather than the list,
I really hope no offense is taken when I feed it back to the list, especially
since my answer also tries to address Ray Denenberg's remark about objections
to the bf:uri property.

Am 17.07.2014 00:01, schrieb Karen Coyle:
>
> On 7/16/14, 1:45 PM, Thomas Berger wrote:
>> Listing strings and URIs (perhaps not as identifierValue but
>> as an hypothetic identifierURI) within the same container is
>> not contradictory on a formal level, I think.
> The problem there was precisely addressed in:
>
> http://listserv.loc.gov/cgi-bin/wa?A2=ind1407&L=bibframe&T=0&P=8029
>
> As Rob says there, and Ray and Kevin concur, it is a problem if the same URI is
> used to represent more than one thing. I would expect reasoners to choke on this
> as an inconsistency.
>
> It is NOT a problem to have multiple URIs for the SAME thing, and, sure, you can
> say that they are the same identifier in a different form. But you should not
> expect to use a URI both as an object of the property bf:identifier and as a RWO.

Sure. But Rob's (absolutely valid) point are the inconsistencies arising
from resource URIs we want to distinguish as "identifiers" simultaneously
used as resource URI for the bf:Identifier as such. Making statements about
some URIs (as URIs as in contrast to the resources they represent) would
constitute a more subtle form of the same(?) fallacy and is likewise absolutely
not admissible.
My point of view however would be to simply dispense n URIs into m bf:Identifier
containers and keep them striclty in object position there...

We could write

<http://www.example.org/xyz>
  a bf:Instance;
  ... our description ... ;
  owl:sameAs <urn:isbn:1-2-3>, <info:isbn/1234> .

but this really are just two odd URIs we additionally provide. To conclude
any connection with the ISBN system is a delusion arising from the fact that
we humans cannot resist interpreting URIs and charging them with meaning we
strive to detect in their string representation (Imagine this was an HTML
formatted mail and I would provide a QR code instead of a string between the
angle brackets.)

On the other hand a graph

<http://www.example.org/xyz>
  a bf:Instance;
  ... our description ... ;
  bf:identifier [
      a bf:Identifier,
      bf:identifierScheme "ISBN",
      bf:identifierValue "978-1-2-3",
      bf:identifierValueURI <urn:isbn:978-1-2-3>, <info:isbn/123> .
    ] .

would assert that within the semantic context of "ISBN"
the two URIs provided
a) "make sense" (meet a certain consensus about admissible
   denominations) [or is this already a fallacious statement
   /about/ the URIs as such?]
and b) their corresponding resources are equivalent to
   our resource
and therefore c) their corresponding resources are
   the same.
This still does not open the URIs given to analysis or algorithmic
transformations but at least establishes their "ISBN" context.

Alternatively we (not RDF) could transform the URIs into literals and
state

<http://www.example.org/xyz>
  a bf:Instance;
  ... our description ... ;
  bf:identifier [
      a bf:Identifier,
      bf:identifierScheme "ISBN",
      bf:identifierValue "978-1-2-3",
      bf:identifierValueURIasString "urn:isbn:1-2-3", "info:isbn/1234" .
    ] .

These strings cannot be used as URIs any more but instead are open
to inspection and algorithmic transformations.

Usage of identifierValueURIasString instead of a plain identifierValue
would indicate that this literal could be turned into an URI by
mechanisms outside of RDF. The distrinction would be simply for the
convenience of the human reader...

Technically the basic thing we need our (real world, traditional)
identifiers for is comparison (the real world tasks like "hunting
down" I mentioned before are dealt with differently in semantic web
contexts), but preferably according to the rules of the scheme
they are taken from. For the three forms given in the example
already we are stating their identity thus both versions serve our
need. For other forms we may encounter in different graphs
we could employ an hypothetical, "ISBN"-specfic canonicalization
service of our choice - and perhaps it is more feasible to encode
strings as parameters in URL construction for that service
than URIs.

As mentioned the string "ISBN" as value for bf:identifierScheme
is not a favorable way of fixating the scheme. Bibframe also provides
the "isbn" subproperty with isbn10 and isbn13 sub-subproperties

The official example

<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
    bf:hasInstance [ a bf:Instance ;
            bf:isbn13 <http://isbn.example.org/9780738609089> ] .

does not tell us about the ISBN as a real world identifier,
we'll have to resort to <http://isbn.example.org/9780738609089>
(read: <http://my.volatile.private.isbn.identifier.store.example.org>)
first and may see there:

<http://isbn.example.org/9780738609089> a bf:Identifier ;
  bf:identifierScheme "ISBN";
  bf:identifierValue "978-0-7386-0908-9".

Or combined and restated the preferred way with an anonymous node:

<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
    bf:hasInstance [ a bf:Instance ;
            bf:isbn13 [ a bf:Identifier ;
                bf:identifierScheme "ISBN";
                bf:identifierValue "978-0-7386-0908-9".]
                   ] .

By using the bf:isbn13 property our bf:Instance very strictly
"knows" what kind of identifier it is referring to, however
the identifier resource as such just vaguely performs an
incantation of "ISBN": IMHO a grave deficiency of the current
design.
Can this be remedied by also admitting the bibframe vocabulary for
the subproperties as range for bf:identifierScheme instead of
literals?

<http://isbn.example.org/9780738609089> a bf:Identifier ;
  bf:identifierScheme bf:isbn;
  bf:identifierValue "978-0-7386-0908-9".

yielding

<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
    bf:hasInstance [ a bf:Instance ;
            bf:isbn13 [ a bf:Identifier ;
                bf:identifierScheme bf:isbn;
                bf:identifierValue "978-0-7386-0908-9".]
                   ] .

Or maybe the other way round:

<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
    bf:hasInstance [ a bf:Instance ;
            bf:isbn [ a bf:Identifier ;
                bf:identifierScheme bf:isbn13;
                bf:identifierValue "978-0-7386-0908-9".]
                   ] .

or more generic

<http://id.loc.gov/resources/bibs/17082740> a bf:Work ;
    bf:hasInstance [ a bf:Instance ;
            bf:identifier [ a bf:Identifier ;
                bf:identifierScheme bf:isbn13;
                bf:identifierValue "978-0-7386-0908-9".]
                   ] .

However ISBN-10/ISBN-13 issues are peculiar to the ISBN system
requiring a more thorough discussion I do not deem appropriate
in this thread.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iJwEAQECAAYFAlPHqOAACgkQYhMlmJ6W47MuAQP/bVsrm24z3x1nw/CY+qGpT6xN
2LXbDw/R3cl/AYRTy9tBDEoPr62rR51kWVCclPATeszmV+ViAnf9+me7WZdLwD9o
+t/Z4xwpnAKgsV69e6I7Scflabj/P+mu6iYdj12ld2mK/FQaaFK3RTAwgvmACcku
s5kCgC/6hFJsCmlZ4F4=
=m9X3
-----END PGP SIGNATURE-----

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

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
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