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

Hi Lars,

Thanks for the reply.

On 6 Oct 2010, at 12:37 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>> Just wondering why this is such a big deal in practice.  Can't you
>> just create a topic representing the author automatically as part of
>> the processing phase and then add reification information at a later
>> stage (if and when it actually becomes required)?
> 
> Yes, I could do that. In the Atom 1.0 -> XTM 2.1 mapping I do exactly
> that (if no atom:email or atom:uri is provided). That's the reason for
> the "Patrick Durusau"-problem. ;) Patrick shows up several times in
> the TM-Planet -> XTM 2.1 topic map with different identities (item
> identifiers).

...and presumably that could be fixed by adding reifiers to each of those item identifiers, right?
That should cause them to all merge nicely and while you'd have several different topic identifiers, they'd all reify the same thing, so this becomes a system artifact and not a user visible problem.

> RTM [1] is a different story: It provides currently no mechanism to
> create topics from strings / RDF literals. We could fix RTM and
> mandate that a topic with an item identifier is created if a string
> should play a role in an association (currently it's an error). The
> string / literal could be mapped to an occurrence or name of the
> automatically generated topic.
> 
> WD 29111 [2] is also silent about the algorithm how to map strings /
> literals to topics. And as long we don't have an algorithm, it seems
> to be safer to map strings / literals to occurrences rather than to
> associations, even if this mapping is less elegant and you could argue
> that this mapping would be semantically wrong, since the creator of a
> blog entry shouldn't be an occurrence of the blog entry.
> 
> Maybe RTM and WD 29111 should provide an algorithm to map strings /
> literals to topics.


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).

I don't think you can have a generic algorithm to map arbitrary strings to anything.  Again, what we do is provide ontology-based normalizations to attempt to minimize the "Patrick Durusau" problem ;) and then, when the conflicting/redundant references are discovered, tie them together with reification.

Putting a bunch of what I would consider ontology-specific rules into RTM seems like a bad idea.  WD 29111 is a different beast because it's actually describing the ontology, not a generic mechanism for mapping between ontologies between different representations.  I've never done much more than skim RTM, so I don't claim to be an expert or understand how its used in practice.

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.

Unless the translator a) "understands" the semantics of the representation as well as the syntax or b) a human provides extra ontology-specific translation guidelines, I don't see how you're going to effectively solve the problem.  Option a) would certainly add some complexity to the software, but it might be necessary to ensure that the resulting translation was actually useful in practice.  Currently, we're towing the option b) line... ;)

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

Thanks for the explanation,

ast
--
Andrew S. Townley <[email protected]>
http://atownley.org