Re: bibliographic issues

From: Eric Miller <>
Date: Tue, 2 Aug 2005 10:48:07 -0400

On Aug 2, 2005, at 10:03 AM, Bruce D'Arcus wrote:
> Right, right; I'm currently just working on the XSLT and figuring
> out basic structure. I've not gotten to that (important) bit.
>>> <published>
>>> <date>
>>> <year>1990</year>
>>> </date>
>>> </published>
>> I don't think the above means what you think it means :)
>> dcterms:issued may be closer.
> So is it then appropriate to do:
> <dct:issued>
> <date>
> <year>2000</year>
> </date>
> </dct:issued>
> ... ?

If you want to say "uri:foo was published in 2000" than all you need is


> I'm thinking about representing dates like "October 1, ,3, 6-10,
> 2001" or "Summer 2000" or "April/May 1999", so I think reification
> is important.

I think datatypes might be more appropriate here for a way of
indicating particular content structure.

>>> <foaf:Person rdf:about="people#gettys-j">
>>> <foaf:givenname>Jim</foaf:givenname>
>>> <foaf:family_name>Gettys</foaf:family_name>
>>> </foaf:Person>
>> Representing people's names is easy to do, but not easy to do well.
> Indeed, dates and names are the two hardest bits to represent in my
> mind. I chatted with Morten about his FOAF names proposal way
> back, but it seems it's still stuck as just a proposal.

Thats 'cause its hard :) More below...

>> Getting various content providers to agree on *a few* properties
>> when it comes to describing peoples for bibliographic description,
>> however, is a small but useful step. For the content providers
>> that are reading this list, I'm wondering if the following might
>> be a simple core folks could agree on...
>> <foaf:Person>
>> <rdf:value>Jim Gettys</rdf:value> <!-- default value for apps
>> that don't know foaf -->
> Why wouldn't you use foaf:name?

You could certainly.

And for a "default name" for subject terms you could use
skos:preferLable and for geographic places you could use geo:place
for the "default name" and for ... (insert favorite vocab here)

But there are several issues worth thinking about. Not all
applications are going to know FOAF (or SKOS or GEO or..)
vocabularies so providing some default value / hint which they do is
often helpful. Also, if each class of object has their own 'default
value' property, then it puts more of the smarts in the application
than the data. The Fresnel [1] work that Simile is doing will
certainly make this easy to manage on *our* end, but for other
applications out there similar mapping will have to be done.


And finally (more of a philosophy than an issue) but I find the
'reuse rather than reinvent' view of vocabulary building to be a
healthy one. From my perspective, if there is a term already out
there that is in use, it makes sense to reuse these rather than
reinvent a new one.

 From Alf's responses I feel that he and I are in agreement that at
least 3 (some-notion-of-default, givenname, surname) properties make
sense. At this point I have a *slight* preference for the more
general rdf:value solution rather than the class specific foaf:name
one. But from my perspective, if content providers could agree to
*any* 3 that addressed these requirements it would be a "good thing"
TM :)

> I think that's a reasonable short-term solution, but what about if
> you need to represent a name in Mandarin (with a family/given sort
> order) and also its Latin transliteration? I could be wrong, but
> doesn't "surname" still presume Western sort order?
> This is the sort of thing I was talking to Morten about ;-)


I'm afraid various specific experiences in building systems and the
more general DCMI discussions of this issue have left me more in a
"lets-just-try-something" mode that correspond roughly to the
approaches Andrew outlined...

4. Approaches to Expressing Names

It is unlikely that there will be agreement on a single common way of
representing names. The following are the preferred methods, in order
of preference.

This translates to use foaf:givenname, foaf:surname when appropriate,
and as new properties (e.g. clanname (Indonesian), baptismalname
(Filipino), etc.) are needed they're defined. This in conjunction
with a 'default' property that would capture more of the local
customs (e.g. Indian / Sikh would be <GivenName> Singh <FamilyName>
(for Male) or <GivenName> Kaur <FamilyName> (for Female)) I think
might be a helpful step.

make sense?

eric miller                    
semantic web activity lead     
w3c world wide web consortium  
Received on Tue Aug 02 2005 - 14:44:43 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:18 EDT