Fine structure of names in BIBO
PK
for biber/biblatex but I have a bit of a stumbling block with names.
In the biber/bibaltex world, names are first-class data objects as it
is critical to sort/typeset them correctly. As a result, we have a lot
of complex code in biber dedicated to breaking names into their
smallest parts so that we can sensitively deal with them when it comes
to truncation, initials generation, sorting etc. It seems that there
isn't too much emphasis on this, naturally, in the general
bibliography ontologies which makes them a bit less appealing to
projects like biber/biblatex which need the data for a specific type
of presentation. I am wondering what the feelings are about adding
such fine-grained structure for names, specifically:
* Other parts of names like title, prefix and suffix
* Sub-parts of names to deal with things like "Frank Lloyd Wright"
where the first name has two
parts or similar cases with double (or more) family names
* Hyphenated name parts
* Middle names
* Explicit initials for name parts which would be modelled as <name
part> <initial> "I", for example
All of these are real concerns for a general bibliography typesetting
system dealing with the arbitrary requirements of journal styles, for
example. All of the above are currently dealt with in code which
parses the data from, for example, bibtex data sources. Some, like
middle names, are just impossible to disambiguate from double first
names in general. It would be nice if there were a data source like
BIBO which could model this and save us having to parse it from simple
"first/last" name data.
Bruce D'Arcus
As I mentioned on the Zotero list, in BIBO, we defer to FOAF for agent
representation, including names.
More generally, my priorities have been to balance a few different,
sometimes competing, needs, like:
1) having enough structure to be able to reliably format common
Western names, but also names in other traditions with different rules
on sorting and display
2) straightforward enough that it maps fairly easily from human input (in a GUI)
3) round-tripping of data; a processor can output formatted reference
lists with embedded RDFa that can easily extracted
4) related, to fit into the wider linked data world, and so to be
consistent with how similar thing (like people) might be represented
outside the bibliographic world
All of this means, for example, notions like "first name" or "middle
name" fail, both because of the lack of international-friendliness
("Mao Zedong" sorts on the "first name" and displays the same as it
sorts), but also because of corner-cases in Western names (like "H.
Rap Brown").
Notions of discrete name parts fail in any unordered model, because
recording the order adds costly complexity. So in BIBO/FOAF, you'd
just do:
<http://example.net/flw> a foaf:Person ;
foaf:givenName "Frank Lloyd" ;
foaf:familyname "Wright" .
And if a processor has to parse that to do something special (like
initialization), so be it.
Ditto with hyphenated name parts.
So that leaves:
- prefix/suffix
- title
- articles (one you did list; common examples are "van" and "de")
It seems to me all of these could be added to FOAF fairly easily, in
the sense they would fit the model. Not sure if this has been
discussed or not. Dan?
Also, one of the beauties of RDF is its extensibility. There's no
reason at all one couldn't invent properties to deal with these data,
and use it seamlessly with FOAF, etc. Unlike in XML, there's no reason
to invent a new model and syntax if you find a gap.
Aside: in the JSON representations some of us were working on for
direct input into CSL processing tools (citeproc-js and citeproc-hs;
somewhat less so my own python implementation), we do have explicit
data structures for the above. Example:
"author": [
{
"comma-suffix": true,
"family": "Doe",
"given": "James",
"static-ordering": false,
"suffix": "Jr"
}
],
... or:
"author": [
{
"family": "Doe",
"given": "John",
"non-dropping-particle": "von",
"static-ordering": false
}
],
Yup, there's two kind of particles in the model.
Not the most human-friendly thing in the world, but we determined
something like this was needed to support the processing use cases.
This work was helped a lot by contributors like Frank Bennett (who
happens to live and work in Japan) and Rintze Zelle, who's Dutch (and
so very familiar with funky article issues).
Bruce
Rob Styles
I have heard many people say that they can't model names as it's just
too hard. FOAF didn't really try. There are complexities as you list
in your example and other complexities as you enter different cultures
where family name and given name are reversed, and more. Adding in
titles (mr, mrs, dr, lt general etc) and professional qualifications
(MD, DDS, MPhil) and it gets big.
If you have a formal description of some or all of that in
biber/biblatex then it would be great to have that published as a
names ontology to fill that gap.
rob
> --
> You received this message because you are subscribed to the Google Groups "Bibliographic Ontology Specification Group" group.
> To post to this group, send email to bibliographic-ontolog...@googlegroups.com.
> To unsubscribe from this group, send email to bibliographic-ontology-spec...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/bibliographic-ontology-specification-group?hl=en.
>
>
--
Rob Styles
http://dynamicorange.com
Ivan herman
http://www.w3.org/Submission/vcard-rdf/
ie, using it together with BIBO is easy...
Ivan
----
Ivan Herman
Bankrashof 108, 1183NW Amstelveen, The Netherlands
tel: +31-641044153;
URL: http://www.ivan-herman.net
Dan Brickley
> This sounds like a really interesting opportunity.
It's a problemtunity :)
> I have heard many people say that they can't model names as it's just
> too hard. FOAF didn't really try.
We bravely ran away!
http://delicious.com/danbri/names ->
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
http://blog.jclark.com/2007/12/thai-personal-names.html
http://rishida.net/blog/?p=100
...were enough to put me off. Nobody does this stuff well. The
comments in those posts are worth reading too.
Richard Ishida's post ends with, "If designing a form or database that
will accept names from people with a variety of backgrounds, you
should ask yourself whether you really need to have separate fields
for given name and family name."
I'm certainly not against attempting to include more subtlety in FOAF
when describing people's names, but it is a daunting task.
My instinct is to explore use of text markup rather than breaking it
into properties, eg. in RDF an XML literal with tagged <spans>. I'd
also consider adding a mechanism that allows a person to say how a
name is pronounced (either sound sample, or IPA markup). Both would
probably require having human names as first class entities, which
means figuring out a nice property name for linking the person to a
name-as-a-thing; re-using foaf:name probably not ideal.
Regarding details,
- prefix/suffix
- title
- articles (one you did list; common examples are "van" and "de")
We do btw have foaf:title,
http://xmlns.com/foaf/spec/#term_title
"title - Title (Mr, Mrs, Ms, Dr. etc) "
... and a hanging suggestion that we migrate to using the wordily
named honorificPrefix to match Portable Contacts.
But what exactly was meant here by title? I notice
http://www.w3.org/Submission/vcard-rdf/ uses it for 'job title', which
makes sense since it is very addressbook/contacts focussed. In a more
static bibliographic context, authors have probably a variety of job
titles over the years.
Anyhow re FOAF I'm pretty open about adding things, but will bias
towards things (such as pronunciation info) that apply to all peoples
and culture rather than a subset. Suggestions welcomed...
cheers,
Dan
PK
types of things as biblatex (sorting, formatting considerations etc.)
which we need to handle inside the LaTeX engine and we already have
covered. It's the data presentation format which we need to eventually
change.
I would probably agree about the initials problem as it's not that
hard to solve (but you do have to deal with cases like "Smith-Jones" -
users may want "S", "S-J" or "SJ" perhaps wih periods too) but the
name parts thing is a problem because there is no way of determining
from a string with spaces whether some part is a first name, middle
name or whatever - they are all just "given name". The simple string
gets round the ordering problem as strings are naturally ordered but
it doesn't semantically discriminate the roles of the parts. It's not
that this can be left to some post-processing, it can't be processed
at all, which is a shame. It's not clear what to do about this. It
does make a difference for styes which want you to only initial middle
names - "John F. Doe". How do you do "Frederick James Alan Smith"
since it's not clear whether "James" (or indeed "Alan") is a first
name or a middle name. This impacts sorting (since we have arbitrarily
customisable sorting schemes in biber), label generation for styles
which use labels based on initials, tracking of name/year combinations
etc. This isn't a modern Western bias really, it would also apply to
dealing with things like patronyms and matronyms which are fairly
common. These are often sorted differently (or ignored for sorting
etc.) and you can't do that unless they are reliably identifiable
(that is, tagged).
PK
we're looking for something really. Up until recently, we've been
relying on bibtex files which are essentially a hack which deal with
some cases by grouping with {braces}.
>
> --
> Rob Styleshttp://dynamicorange.com
Rob Styles
biblatex etc haven't solved the problem and so much is down to
personal preference, local culture and folklore that this problem is
intransigent.
Allow people to enter multiple forms of the name, each as literal strings?
rob
> --
> You received this message because you are subscribed to the Google Groups "Bibliographic Ontology Specification Group" group.
> To post to this group, send email to bibliographic-ontolog...@googlegroups.com.
> To unsubscribe from this group, send email to bibliographic-ontology-spec...@googlegroups.com.
Bruce D'Arcus
I think PK's meaning of title in this thread = foaf:title.
As you note above, one easy addition to FOAF would be what in vCard
are called honorific prefix and suffix.
Bruce
Bruce D'Arcus
<rob.s...@dynamicorange.com> wrote:
> so, to conclude, FOAF (bravely, and quite sanely) ran away, bitex,
> biblatex etc haven't solved the problem and so much is down to
> personal preference, local culture and folklore that this problem is
> intransigent.
Beautifully put :-)
I would just add to the conclusion Ivan's point, which is that vCard's
name modeling is more complete (and also more complex).
> Allow people to enter multiple forms of the name, each as literal strings?
Yeah, Ian Davis once suggested that.
Bruce
Christopher Gutteridge
In EPrints we used honourific, givenName, familyName, lineage
where lineage is the VIII in Henry VIII or the Junior in John Smith Junior
I think the two really valuable bits of data are
foaf:name (a string of how to print the whole name)
and
foaf:familyName (the thing you generally sort alphabetically by)
breaking everything else down into components feels a bit like
over-modelling to me. What's the use case where a system NEEDS to know
the semantics of every part of a name? Who benefits from this increase
in complexity?
--
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248
/ Lead Developer, EPrints Project, http://eprints.org/
/ Web Projects Manager, ECS, University of Southampton, http://www.ecs.soton.ac.uk/
/ Webmaster, Web Science Trust, http://www.webscience.org/
Bruce D'Arcus
<c...@ecs.soton.ac.uk> wrote:
...
> breaking everything else down into components feels a bit like
> over-modelling to me.
I agree.
> What's the use case where a system NEEDS to know the
> semantics of every part of a name? Who benefits from this increase in
> complexity?
A citation processing tool that has to create output that perfectly
conforms to odd and archaic citation style rules; rules that say
things like "initialize given names" or "initialize middle names" or
(effectively) "sort and index by last name, disambiguate by given
name", etc.
But as I say, I really want to get to a place where these tools can
generate RDFa-enhanced HTML, so some sanity in modeling is important.
Bruce
Christopher Gutteridge
At one point we thought that items had creators, and creators had names. Not so....
well not exactly.
It turns out that we often want to know the authors identity, but the name as it appeared on the item.
So we often have a single person with different names, often less formal and more formal depending on where the item was published.
To summarise the summary of the summary; people are a problem.
Christopher Gutteridge
could I ask that any documentation or guidelines should make it clear
that what ever detail you model a name to, it's best practice to always
include a basic foaf:name string.
--
PK
more concerned that no model so far can deal with fairly common cases
in, say, Western academia. I'd rather have a model which at least
covered the basics for most of Western publishing than just give up in
despair over, as you say purely fictional completeness ...
Now, I'm happy to continue to hack all this in biber but really, this
is what models are for.
PK
more concerned that no model so far can deal with fairly common cases
in, say, Western academia. I'd rather have a model which at least
covered the basics for most of Western publishing than just give up in
despair over, as you say purely fictional completeness ...
Now, I'm happy to continue to hack all this in biber but really, this
is what models are for.
On Feb 18, 2:52 pm, Rob Styles <rob.sty...@dynamicorange.com> wrote:
Bruce D'Arcus
> Well, it's clear that there is no way to comprehensively do this. I'm
> more concerned that no model so far can deal with fairly common cases
> in, say, Western academia. I'd rather have a model which at least
> covered the basics for most of Western publishing than just give up in
> despair over, as you say purely fictional completeness ...
> Now, I'm happy to continue to hack all this in biber but really, this
> is what models are for.
We have a number of models, and I'd submit they're "good enough."
Right now, for example, you can use the vCard representation to cover
the vast majority of cases in an international-friendly way.
Right now, you could use foaf for the same thing, and add two
properties: honorificPrefix and honorificSuffix. And/or you could wait
to see if Dan adds those in the foaf namespace.
Bruce
> For more options, visit this group at http://groups.google.com/group/bibliographic-ontology-specification-group?hl=en.
>
>
Dan Brickley
> On Fri, Feb 18, 2011 at 12:41 PM, PK <Phi...@kime.org.uk> wrote:
>> Well, it's clear that there is no way to comprehensively do this. I'm
>> more concerned that no model so far can deal with fairly common cases
>> in, say, Western academia. I'd rather have a model which at least
>> covered the basics for most of Western publishing than just give up in
>> despair over, as you say purely fictional completeness ...
>> Now, I'm happy to continue to hack all this in biber but really, this
>> is what models are for.
>
> We have a number of models, and I'd submit they're "good enough."
>
> Right now, for example, you can use the vCard representation to cover
> the vast majority of cases in an international-friendly way.
>
> Right now, you could use foaf for the same thing, and add two
> properties: honorificPrefix and honorificSuffix. And/or you could wait
> to see if Dan adds those in the foaf namespace.
Can you help me understand how honorificPrefix relates to foaf:title
and other notions of title, then?
cheers,
Dan
Bruce D'Arcus
Actually, I believe that an honorific prefix is equivalent to
foaf:title. An hCard example I found on the web*:
<span class="vcard">
<cite class="fn n">
<span class="honorific-prefix">Dr.</span>
<span class="given-name">John</span>
<abbr class="additional-name" title="Quinlin">Q.</abbr>
<span class="family-name">Smith</span>,
<span class="honorific-suffix">M.D.</span>
</cite>
</span>
Bruce
Bruce D'Arcus
On Fri, Feb 18, 2011 at 3:29 PM, Bruce D'Arcus <bda...@gmail.com> wrote:
>> Can you help me understand how honorificPrefix relates to foaf:title
>> and other notions of title, then?
>
> Actually, I believe that an honorific prefix is equivalent to
> foaf:title. An hCard example I found on the web*:
>
> <span class="vcard">
> <cite class="fn n">
> <span class="honorific-prefix">Dr.</span>
> <span class="given-name">John</span>
> <abbr class="additional-name" title="Quinlin">Q.</abbr>
> <span class="family-name">Smith</span>,
> <span class="honorific-suffix">M.D.</span>
> </cite>
> </span>
... it might be that foaf:title is technically slightly narrower? I
believe there are some prefixes in other language (Arabic?) that may
not technically be titles.
<http://en.wikipedia.org/wiki/Honorific#Prefix_type>
Bruce