Adding additional identifiers, such as bibo:handle and bibo:oai
Rod Page
ISSNs, ISBNs, PubMed numbers, Amazon Standard Identification Numbers,
etc.
Are there plans to add Handles (http://www.handle.net)? These are
widely used in DSpace repositories, for example, and my own
bibliographic database has hundreds of records for which a Handle is
the primary identifier.
Another possible identifier is the OAI identifier used, for example,
to identify (and retrieve) individual records using the OAI Protocol
for Metadata Harvesting (OAI-PMH). Once again, DSpace repositories are
one example of this use.
While it's easy to start multiplying identifiers, I think these may be
of general use, especially given the broad adoption of DSpace by
institutional repositories (http://www.dspace.org/index.php/DSpace-
Instances/Repository-List.html)
Regards
Rod
Bruce D'Arcus
>
> The ontology currently includes support for identifiers such as DOIs,
> ISSNs, ISBNs, PubMed numbers, Amazon Standard Identification Numbers,
> etc.
>
> Are there plans to add Handles (http://www.handle.net)? These are
> widely used in DSpace repositories, for example, and my own
> bibliographic database has hundreds of records for which a Handle is
> the primary identifier.
>
> Another possible identifier is the OAI identifier used, for example,
> to identify (and retrieve) individual records using the OAI Protocol
> for Metadata Harvesting (OAI-PMH). Once again, DSpace repositories are
> one example of this use.
For those of us that are busy, can you condense the request down to a
sentence or two, with examples? I'm not willing to wade through the
specs myself.
Bruce
Rod Page
Handles
=======
Please add bibo:handle to support Handles (which is the technology
underlying DOIs). An example handle is hdl:2246/5781, which can be
resolved at http://hdl.handle.net/2246/5781. Hence, I'd like
<bibo:handle>2246/5781</bibo:handle>
You could also write it as an info URI (prefix info:hdl/), but that's
too ugly for words, and hardly anybody I know uses them. The Handle
would just be a text string as there's more than one way to resolve
them (for example, http://dx.doi.org/2246/5781 ).
OAI
===
Please add <bibio:oai>, with the content being a text string
identifier. For example, for the paper http://hdl.handle.net/2246/5781
the OAI identifier is oai:digitallibrary.amnh.org:2246/5781, so
<bibo:oai>oai:digitallibrary.amnh.org:2246/5781</bibo:oai>. Resolution
would require knowing how to talk to the repository, but that's for
the client software to figure out.
How's that?
Regards
Rod
On Jul 9, 7:22 pm, "Bruce D'Arcus" <bdar...@gmail.com> wrote:
>
> > The ontology currently includes support for identifiers such as DOIs,
> > ISSNs, ISBNs, PubMed numbers, Amazon Standard Identification Numbers,
> > etc.
>
Mark Diggory
format of the handle and expect that tools would do the info:hdl/ and
http://hdl.handle.net/ parsing if it were present
Mark
--
Mark R. Diggory
@mire - http://www.atmire.com
Ross Singer
In both cases you're talking about fairly easily parseable URIs
(assuming you use handle's http or info uri formats, which I would
recommend, anyway).
Would bibo:doi be a subtype of bibo:hdl?
What is the use case for using an OAI identifier in a citation?
-Ross.
Bruce D'Arcus
...
> How's that?
Helpful; thanks (though I'm left scratching my head again; what
happened to URIs?).
I have no particular opinion about whether or not to add it, but
generally take the position "if in doubt, add it." Curious what others
think.
Bruce
Roderic Page
On 10 Jul 2009, at 04:05, Bruce D'Arcus wrote:
>
> On Thu, Jul 9, 2009 at 2:58 PM, Rod Page<rdm...@googlemail.com>
> wrote:
>
> ...
>
>> How's that?
>
> Helpful; thanks (though I'm left scratching my head again; what
> happened to URIs?).
schemes, many of which either predate the web, or are designed to
outlast it ;)
Plus, we have many sources of information about the same objects, so
having HTTP URIs as the primary identifier privileges certain sources,
which is why it is useful to have a ISBN number rather than just a URL
for the book in amazon.com.
Regards
Rod
Rod Page
On Jul 10, 4:01 am, Ross Singer <rossfsin...@gmail.com> wrote:
> Would dcterms:identifier not work for both of these use cases?
>
> In both cases you're talking about fairly easily parseable URIs
> (assuming you use handle's http or info uri formats, which I would
> recommend, anyway).
dcterms:identifier) and put anything in there. This means client has
to parse identifier and figure out what to do. One problem is that
there may be multiple ways to write the same identifier:
http://dx.doi.org/10.1111/j.1365-2699.2007.01861.x
doi:10.1111/j.1365-2699.2007.01861.x
info:doi/10.1111/j.1365-2699.2007.01861.x
So, client has to cope with these (=hassle).
Alternative is to multiply types so that we can dispense with
namespace prefixes, HTTP proxies, etc. This is the approach taken by
PRISM (e.g., prism:issn, prism.eIssn, prism:doi) and by bibo (you
already have asin, issn, eissn, pmid, doi, etc.). Since bibo has
started down this route, adding bibo:handle (or bibo:hdl) seems
trivial.
The cost is different vocabularies may put the same identifier in
different places. I guess the choice is whether to embed semantics in
the identifier, or in the vocabulary.
Personally I won't recommend using (just) Handle's HTTP format -- why
tie an identifier to just one way of resolving it?
And info uri is just an ugly mess. Who actually uses these? By "use" I
mean consume, not publish.
>
> Would bibo:doi be a subtype of bibo:hdl?
>
> What is the use case for using an OAI identifier in a citation?
citation? Nobody that I'm aware of uses them in a citation as such,
but they're a very useful part of the description of an article.
If one aim of bibo is to describe the objects being cited, then don't
we want information which would be useful in finding out more about
that object?
Given oai:digitallibrary.amnh.org:2246/5781, I can retrieve metadata
about that object:
http://digitallibrary.amnh.org/dspace-oai/request?verb=GetRecord&identifier=oai:digitallibrary.amnh.org:2246/5781&metadataPrefix=oai_dc
This is more than I can do if I have http://hdl.handle.net/2246/5781
(which gives a web page with a link to the document PDF, but not
metadata).
Regards
Rod
>
> -Ross.
>
>
>
> On Thu, Jul 9, 2009 at 3:03 PM, Mark Diggory<mdigg...@gmail.com> wrote:
>
> > Yes, I think this would be a useful addition. I would not restrict the
> > format of the handle and expect that tools would do the info:hdl/ and
> > Mark
>
> > --
> > Mark R. Diggory
> > On Thu, Jul 9, 2009 at 11:58 AM, Rod Page<rdmp...@googlemail.com> wrote:
>
> >> OK,
>
> >> Handles
> >> =======
>
> >> Please add bibo:handle to support Handles (which is the technology
> >> underlying DOIs). An example handle is hdl:2246/5781, which can be
> >> <bibo:handle>2246/5781</bibo:handle>
>
> >> You could also write it as an info URI (prefix info:hdl/), but that's
> >> too ugly for words, and hardly anybody I know uses them. The Handle
> >> would just be a text string as there's more than one way to resolve
> >> them (for example,http://dx.doi.org/2246/5781).
>
> >> OAI
> >> ===
>
> >> Please add <bibio:oai>, with the content being a text string
Mark Diggory
>
> Would dcterms:identifier not work for both of these use cases?
and ASIN as well. If that is the case, why differentiate at all with
subproperties for them? I assume because they did so in dcterms.
IMO, Handles and DOI are rather the same as ISSN, ISBN, PubMed and
ASIN etc. I suspect there is a limited risk here of having BIBO end up
having add new identifier properties every time they are cooked up.
However, I still suggest the addition here because hdl and doi are
used quite a bit in citing digital resources. Likewise, lsid, arXiv,
> In both cases you're talking about fairly easily parseable URIs
> (assuming you use handle's http or info uri formats, which I would
> recommend, anyway).
http://hdl.handle.net/1234.5/67890 is not a "Handle", Perhaps I should
be more cautious about about suggesting use of a URI like syntax.
Note that "1234.5/67890" "could possibly be" a handle. but without
some standard scheme, its inconclusive.
1.) hdl:1234.5/67890 is often an observed representation in the wild,
and is not a registered URI even though it looks like one.
2.) http://hdl.handle.net/1234.5/67890 is a URI but not really a
"handle" though many apps will attempt to process it if they encounter
it.
3.) info:hdl/1234.5/67890 is a valid registered representation for a
handle and practically never used because people don't understand why
its important to use a registered URI scheme:namespace to disambiguate
identifiers.
So, IMO, a handle is a string identifier, not a URI. Attempts to get
DOI and Handle registered URI schemes (outside of "info") have been
unfruitful. I'd leave the syntax of the Literal up to the user
community to deal with. And, I would recommend saving BIBO users the
torture of parsing indeterminate Literal strings in an attempt to
determine what kind of identifier a string is by assigning properties
for disambiguation where-ever and when-ever possible.
But, conversely, another alternative (or middle ground) may be to
consider the info URI scheme as a "class" of identifiers with an
explicit "info" URI syntax that are disambiguated by their namespaces:
http://info-uri.info/registry/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc
and thus something like this may be appropriate
bibo:info "info:hdl/.../"
bibo:info "info:arXiv/.../"
bibo:info "info:doi/.../"
Then the recommendation would be to use "info" and when asked to add
new properties, the BIBO recommendation would be to register them at
the info registery instead. This would assist in keeping BIBO out of
the business of being a "registry" itself.
> Would bibo:doi be a subtype of bibo:hdl?
much practicality in expressing it so.
http://wiki.tdwg.org/twiki/bin/view/GUID/TechnologyComparison
>
> What is the use case for using an OAI identifier in a citation?
Pete Johnston
> OAI
> ===
>
> Please add <bibio:oai>, with the content being a text string
> identifier. For example, for the paper
> http://hdl.handle.net/2246/5781 the OAI identifier is
> oai:digitallibrary.amnh.org:2246/5781, so
>
> <bibo:oai>oai:digitallibrary.amnh.org:2246/5781</bibo:oai>.
> Resolution would require knowing how to talk to the
> repository, but that's for the client software to figure out.
However, according to the OAI-PMH spec, the oai-identifier identifies
what OAI-PMH calls an "item":
"A unique identifier unambiguously identifies an item within a
repository; the unique identifier is used in OAI-PMH requests for
extracting metadata from the item."
http://www.openarchives.org/OAI/openarchivesprotocol.html#UniqueIdentifi
er
An OAI item is an abstraction specific to the OAI-PMH protocol:
"An item is a constituent of a repository from which metadata about a
resource can be disseminated. An item is conceptually a container that
stores or dynamically generates metadata about a single resource in
multiple formats, each of which can be harvested as records via the
OAI-PMH. Each item has an identifier that is unique within the scope of
the repository of which it is a constituent."
http://www.openarchives.org/OAI/openarchivesprotocol.html#Item
An OAI item is a different thing from the thing(s) which may be
described by the metadata records "disseminated by" an OAI item; the
OAI-PMH spec refers to those described things as "resources":
"Note that the identifier described here is not that of a resource. The
nature of a resource identifier is outside the scope of the OAI-PMH."
So e.g. in a scenario case where OAI-PMH is used to disseminate metadata
records about some bibliographic resources, the OAI identifier
identifies the OAI item which disseminates the metadata records, not the
bibliographic resource described by those metadata records (which is
(typically) the thing identified by a Handle, DOI, etc)
Pete
---
Pete Johnston
Technical Researcher, Eduserv
pete.j...@eduserv.org.uk
+44 (0)1225 474323
http://www.eduserv.org.uk/research/people/petejohnston/
http://efoundations.typepad.com/
Rod Page
<bibo:oai>oai:digitallibrary.amnh.org:2246/5781</bibo:oai> would be
"has OAI metadata item identifier by oai:digitallibrary.amnh.org:
2246/5781" (essentially like rdfs:seeAlso)?
So this an argument for not using
<dcterms:identifier>oai:digitallibrary.amnh.org:2246/5781</
dcterm:identifier> (?)
Regards
Rod
On Jul 10, 11:28 am, "Pete Johnston" <Pete.Johns...@eduserv.org.uk>
wrote:
>
> > OAI
> > ===
>
> > Please add <bibio:oai>, with the content being a text string
> > identifier. For example, for the paper
> +44 (0)1225 474323http://www.eduserv.org.uk/research/people/petejohnston/http://efoundations.typepad.com/
Bruce D'Arcus
>
> So, if I understand you correctly, the interpretation of
> <bibo:oai>oai:digitallibrary.amnh.org:2246/5781</bibo:oai> would be
> "has OAI metadata item identifier by oai:digitallibrary.amnh.org:
> 2246/5781" (essentially like rdfs:seeAlso)?
>
> So this an argument for not using
> <dcterms:identifier>oai:digitallibrary.amnh.org:2246/5781</
> dcterm:identifier> (?)
If I understand Pete right, no; it suggests oai is not an appropriate
identifier for BIBO at all.
This goes back to discussion about items vs. resources w/Zotero.
Bruce
Mark Diggory
True, however, these do leak out into the world from those services as
identifiers:
There are in the example references to the following resources:
http://www.citebase.org/abstract?id=oai:arXiv.org:astro-ph/0601007
and
but I do agree that BIBO doesn't need to create a bibo:oai properties
to support them.
Mark
Frederick Giasson
> I guess there are two approaches. One is to have a generic type (e.g.,
> dcterms:identifier) and put anything in there. This means client has
> to parse identifier and figure out what to do. One problem is that
> there may be multiple ways to write the same identifier:
>
> http://dx.doi.org/10.1111/j.1365-2699.2007.01861.x
> doi:10.1111/j.1365-2699.2007.01861.x
> info:doi/10.1111/j.1365-2699.2007.01861.x
>
> So, client has to cope with these (=hassle).
>
> Alternative is to multiply types so that we can dispense with
> namespace prefixes, HTTP proxies, etc. This is the approach taken by
> PRISM (e.g., prism:issn, prism.eIssn, prism:doi) and by bibo (you
> already have asin, issn, eissn, pmid, doi, etc.). Since bibo has
> started down this route, adding bibo:handle (or bibo:hdl) seems
> trivial.
>
> The cost is different vocabularies may put the same identifier in
> different places. I guess the choice is whether to embed semantics in
> the identifier, or in the vocabulary.
>
> Personally I won't recommend using (just) Handle's HTTP format -- why
> tie an identifier to just one way of resolving i
It really depends on how you see it. Personally I prefer to have a good
hierarchy of properties in place to be able to specialize everything
accordingly. With that mindset, it makes sense to add these properties.
But the question is: why?
Well, there is a reason why we create these ontologies: because we can
reason by using them. With simple inference steps, an application can
easily handle bibp:handle like if it would be handling
dcterms:identifier. Why? Because of this inference path:
bibo:handle -> bibo:identifier -> dcterms:identifier.
So, if your application doesn't know anything about how to handle
bibo:handle, but knows about dcterms:identifier, and can make this kind
of simple reasoning, then it will know how to handle bibo:handle (like a
dcterms:identifier) without knowing anything about this property.
If you only use dcterms:identifier for everything, as you said, it
become a real hassle to users and implementators, and you loose all your
time developing high tech parsers for these kind of properties.
Thanks,
Fred
Frederick Giasson
>> So, if I understand you correctly, the interpretation of
>> <bibo:oai>oai:digitallibrary.amnh.org:2246/5781</bibo:oai> would be
>> "has OAI metadata item identifier by oai:digitallibrary.amnh.org:
>> 2246/5781" (essentially like rdfs:seeAlso)?
>>
>> So this an argument for not using
>> <dcterms:identifier>oai:digitallibrary.amnh.org:2246/5781</
>> dcterm:identifier> (?)
>>
>
> If I understand Pete right, no; it suggests oai is not an appropriate
> identifier for BIBO at all.
>
> This goes back to discussion about items vs. resources w/Zotero.
>
Yes, this is what I understood too. And since bibo:oai would be a
dcterms:identifier by inference, it won't be appropriate neither.
Thanks,
Fred