Hi Adrian:
Thank you! Your interpretation may be closer to the intended usage than my
initial take. I'm going to examine this further and make some suggestions,
but I might be missing something very obvious, and if so, I welcome
enlightenment from the BIBFRAME community!
The supplementary instructions at
http://www.loc.gov/bibframe/docs/pdf/bf2-identifiers-march2017.pdf state
"Along with the identifier value itself, the identifier type must be
conveyed" and that where there is no specific BIBFRAME class for the
identifier, and there is no external class for the identifier, a bf:source
must be supplied. All three examples show an identifier with an rdf:value
of a string literal, but without an example of a URI, it's unclear if the
intention was for all identifier values to be string literals.
Rebecca Younes noted on this list back on 2016-06-22 in the (long!)
"rdf:value" thread: "The range of rdf:value is rdfs:Resource, so the object
can be any type of resource: a URI resource, a blank node, or a literal."
In a linked data context, I think that forcing a URI to be represented as a
literal (with a blank node as a bonus), instead of as the URI it is, is an
anti-pattern.
However, even if we accept that the value of rdf:value can be a URI
resource rather than a literal, we still need to specify the identifier
type. We've already established that there is no existing BIBFRAME
identifier class for URI. So that currently takes us to option #2 or #3 in
the document.
Option #2 is using an external class for the identifier. RDF and RDF Schema
don't seem to define a class for URI/IRI, perhaps because URIs are so core
to RDF / linked data that they just exist and are used directly to identify
things.
A popular external vocabulary that does specify a type of URI as a literal
is http://schema.org/URL. I say "as a literal" because it is a subclass of
http://schema.org/Text, but schema.org tends to err on the side of being
permissive to encourage structured markup of any kind. Indeed, some of the
examples in the schema.org documentation for schema:URL lead to generating
either URIs or literals depending on which serialization (RDFa or JSON-LD)
you choose.
If we do adopt a http://schema.org/URL approach, that would suggest
something like:
@prefix bf: <http://id.loc.gov/ontologies/bibframe/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
<http://example.org/2335409#Work> a bf:Text, bf:Work ;
bf:identifiedBy [ a schema:URL ;
rdf:value <http://worldcat.org/entity/work/id/638612>
] .
If we're not comfortable with adopting http://schema.org/URL or some other
external class, then we're down to #3 -- basically what you suggested, plus
a bf:source [ ] statement, with an uncontrolled string value identifying
URI (oh the irony!):
@prefix bf: <http://id.loc.gov/ontologies/bibframe/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
<http://example.org/2335409#Work> a bf:Text, bf:Work ;
bf:identifiedBy [
bf:source [ rdfs:label "URI"@en ];
rdf:value <http://worldcat.org/entity/work/id/638612>
] .
A few suggestions coming out of this:
1. Given that the identifier type must be conveyed, and URI will hopefully
be a very common identifier type in the linked data environment we're
aiming for, BIBFRAME should either define a bf:URI subclass of
bf:Identifier OR document the recommendation of a common external class
(something like http://schema.org/URL, although that might not be the best
choice).
2. If BIBFRAME wants strings for identifiers, then per Simon Spero's
recommendation in the same 2016-06-22 thread, consider declaring a pair of
new properties that replace rdf:value and rdfs:label with more specific
ranges -- Simon suggested bf:text and bf:res -- and replace throughout the
examples/documentation. That will reduce ambiguity.
Best,
Dan
On Mon, 18 Feb 2019 at 02:56, Adrian Pohl <[log in to unmask]> wrote:
> Hello Dan,
>
> I think we should use a URI in quotes (i.e. as string) when talking
> about itself and not about the thing it identifies:
> <http://worldcat.org/entity/work/id/638612> is a bf:Work while
> 'http://worldcat.org/entity/work/id/638612' is an identifier/URI.
>
> It is similar when we are talking about words (metalanguage) instead of
> just using them: 'long' has four letters.
>
> Regqarding the example case, this would mean to just record the URI as
> if it was a non-URI identifier:
>
>
> @prefix bf: <http://id.loc.gov/ontologies/bibframe/> .
>
> <http://example.org/2335409#Work> a bf:Text, bf:Work ;
> bf:identifiedBy [ a bf:Identifier ;
> rdfs:value "http://worldcat.org/entity/work/id/638612"
> ] .
>
> -Adrian
>
>
> Am 16.02.19 um 01:44 schrieb Dan Scott:
> > While the description for bf:Identifier
> > (http://id.loc.gov/ontologies/bibframe.html#c_Identifier) is "Token or
> > name that is associated with a resource, such as a URI or an ISBN", its
> > subclasses include bf:Isbn but not bf:Uri[1].
> >
> > For now I've interpreted this as "just use bf:Identifier if you have a
> > URI," but if that interpretation is correct, it might make sense to
> > clarify the description.
> >
> > Example:
> >
> > @prefix bf: <http://id.loc.gov/ontologies/bibframe/> .
> >
> > <http://example.org/2335409#Work> a bf:Text, bf:Work ;
> > bf:identifiedBy <http://worldcat.org/entity/work/id/638612>.
> >
> > <http://worldcat.org/entity/work/id/638612> a bf:Identifier .
> >
>
