Re: Status of the Dublin Core to Topic Maps mapping?

Hi Andrew,

[...]
> ...and presumably that could be fixed by adding reifiers to each of
> those item identifiers, right?

You cannot add reifiers to topics / item identifiers, but you could
add an additional identity (manually) to all "Patrick" topics and they
would merge (reifiers are only allowed for assocs, names, occurrences,
and variants, see [1] for the reason)

If I'd use TMRM, it would be possible to keep "Patrick Durusau" as
string and create a proxy with that string and having some cool legend
which says that all Patrick Durusau proxies should merge, though.

[...]
> Being pragmatic about it, normally what I see in practice are names
> of some form or another.  I'd say that potentially without updating
> the specs a "good practice guide" with some additional guidelines on
> how to appropriately leverage the specifications for greater
> interoperability might be a way forward (XML uses this approach for sure).

Yes, might be doable. Although WD 29111 isn't carved in stone and it
would be easy to fix. Maybe it has to be fixed, since the string ->
topic problem is important enough to be specified properly.

[...]
> Putting a bunch of what I would consider ontology-specific rules
> into RTM seems like a bad idea.

I agree, but I don't want ontology-specific rules in RTM, but I want
to extend RTM's vocabulary to let users define their own
ontology-specific rules. A string as role player would still be an
error by default, but a user may specify that a topic should be
created from the string and what happens to the string (becomes a name
or an occurrence of the newly created topic).

[...]
> What the specifications should do is provide an extension point of
> some kind indicating that such ontology-specific mappings for
> strings appearing in certain contexts MUST be defined and this is
> what such a definition would look like.  Also, it wouldn't preclude
> a conformant processor from doing some kind of automatic, fall-back
> translation using a mechanism that could be expressed using the
> same, machine-readable definition.

I think it would be sufficient if WD 29111 would say, that a topic is
created if dc:creator is not an IRI, otherwise the IRI is used as
subject identifier. That puts some burden on the converter since it
must be capable to discover IRIs, though. If we don't want that, we
could simply state, that dc:creator creates produces always a topic
and accept the "Patrick Durusau" problem (sorry Patrick) ;)

[...]
> I guess all that's a long-winded way to say "no, I don't think you
> should allow string literals in dc:creator"! ;)

:) Ideally, dc:creator would contain an IRI, i.e. the e-mail address,
but I don't think that we're able to convince the whole world that the
current usage of dc:creator is wrong and convince the Dublin Core
group to change the specification. :)


[1] <http://www.isotopicmaps.org/sam/sam-model/#d0e997>


Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine