Re: frad:Person and foaf:Person

mån 2010-11-01 klockan 09:14 +0100 skrev Dan Brickley:
> 
> Ok so on this topic of names, I long wanted a class in FOAF that
> stands explicitly for someone's name. The reasons for this I hope are
> also not hysterical, just pragmatic. Sometimes people have several
> names, and unless those are modeled as 'things in themselves', it is
> hard to keep their properties clearly separate. In particular I'd like
> to be able to add pronunciation information (using media files, and/or
> http://en.wikipedia.org/wiki/International_Phonetic_Alphabet) and
> possibly dates. (Genealogy apps might also want to treat names as
> first class things with information about their meaning, associated
> geography etc.).


As a side note, this discussion reminds me very much of a discussion
about titles (not titles IN names, but as in dc:title).

In DCMI, this was reflected in a proposal for a "parallel" property to
dc:title, called dc:titleAsText, the value of which would be a resource
with multiple literal forms (different transcriptions etc.)

http://dublincore.org/usageboardwiki/TitleProposal

The proposal was rejected, but I think Tom knows more about this.

There's a similar problem in RDA, where the title is expected to be
marked up with a "Statement of responsibility" which formally is a
property of the title value, meaning that a "true" modeling would
require the title to be a first-class object.

See http://www.rda-jsc.org/docs/5rda-elementanalysisrev3.pdf, page 11

I think this was solved by introducing a separate property, describing
the statement of responsibility as a property of the original resource. 

This latter pattern is actually quite common, i.e. that two independent
properties of a resource actually describe some common entity which does
not appear explicitly in the model. Examples include:

foaf:familyName and foaf:givenName - which can be seen as properties of
a Name, but are modeled as properties of the person instead.

dc:created and dc:creator - there is an implicit "creation event" that
connects the two properties. In IEEE LOM, events in the lifecycle of a
resource are modeled as first-class "Contribution" objects, with a
"role" property (values are "creator", "illustrator", etc), a "date"
property and an "entity" property, giving the agent.

I think it's important to be aware of the modeling choices and the
strengths and weaknesses of each. Obviously, creating first class
objects for everything one can think of makes the metadata unnecessarily
complex. On the other hand, there are many occasions where it is called
for.

In essence, one extreme is the Simple Dublin Core model of 15
literal-valued properties, and I think we all agree we need to move
beyond that. Exactly what the other extreme is, I'm not sure, but it's
sure fascinating to think about :-). Alas, Mandelbrot is no longer with
us... 

/Mikael

Received on Monday, 1 November 2010 09:04:19 UTC