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

Hi Lars,

On 6 Oct 2010, at 2:44 PM, Lars Heuer wrote:

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

Yeah, sorry.  I forgot about the limitation that topics can't reify other topics.  That actually seems kinda silly to me because I see no difference between two topics in the same map merging and two topics in different maps merging based on reifier information.

Obviously, my TMRM-based system doesn't have this problem... ;)  We would have n proxies with various versions of Patrick in the same map, but then could collect them together via reification into a new proxy representing a dynamically merged view of all of them based on accessing any of them through their original proxy identifier--effectively creating n aliases to the "grand, unified, one true" topic for Patrick.  Our proxies are slightly more sophisticated than a the model you describe, but you're right: what you suggest is certainly a way to provide a simple yet compliant TMRM implementation.

> 
> [...]
>> 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.

In this case, yes, I agree.  There should be specific rules for creating topics/associations from strings for that vocabulary as part of the mapping.  However, I'd say you could probably define them using the same type of mechanism I mentioned before.

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

Then I think we're in agreement.  That mechanism is what I was describing below--naturally without all that pesky implementation-detail-specific junk getting in the way! :)

> [...]
>> 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'm sure you've encountered this too, but there are cases where you need to explicitly differentiate between relative IRIs and string literals at authoring time because, depending on the value, there's no syntactic test to differentiate one from the other.  I'd see this as a problem with RDF data, but maybe it isn't a big deal.  In what I do, I encounter this a lot.

You could certainly say that if the IRI wasn't an absolute IRI, then you'd need to create a topic, but then you'd preclude specifying references to TMDM constructs in the same map--unless I'm mistaken (which happens...from time to time... ;).

If I were implementing a generic converter without any syntactic sugar to tell it what to do, I'd probably attempt to resolve the string as an IRI, then, if that failed, assume that it wasn't already created and therefore create a new reference for that topic.  The down-side with this approach is that then you're applying processing ordering rules to your input, e.g. you must first define all references before you use them.  In practice, this is a PITA, and in systems that take this approach, results in a lot of unwanted, autogenerated topic IDs.

The next solution is two-pass processing, but that assumes that all of your references are resolved in the same processing run and not a subsequent processing run.

(Boy, I'm glad I don't have that topics-can't-reify-topics problem! ;)

> [...]
>> 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. :)

C'mon Sancho!  There's another one!!! ;)

Agreed.  Pick your windmills wisely. :)

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

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