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

On 6 Oct 2010, at 3:57 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>> 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.
> 
> Sorry for being picky here, but merging topics based on reifier
> information is actually possible, even in TMDM ;).
> 
> [...]

> and you'd merge map A and B, the topics "lennon-membership" and
> "johns-membership" would merge since they are reifying the same
> association.
> 
> I don't say that TMDM is cooler than TMRM, but we shouldn't be too
> unfair. ;)

I wasn't trying to say one is cooler than the other, and maybe I misunderstood.  What you describe is what I expected should work, even though I don't regularly think about TMDM nor CTM.

Actually, it was more that reification of topics isn't possible using the same mechanism within the given map.  I realize that this is essentially asking for two ways to do the same thing, and, reading what you wrote originally again, you setting subject identifier on the topics is the same effect as me saying each proxy reifies the same SID (or, in my case, I can even point all of them at a specific proxy to trigger the same behavior--with or without the target proxy actually having a subject indicator or it being a subject identifier.

The main difference I see here is that in my world (implementation), everything's a proxy, so proxies can reify other proxies, and some of those proxies might just happen to be subject indicators, meaning that their proxy identifier (item identifier) just happens to also be a subject identifier.

The net effect of this is that I can "collect" proxy identifier references that may have been created based on different, non-normalized string values for the name of something and based on saying proxy1 is-reified-by proxy2 as opposed to having to modify each of the proxy instances to say that they all represent the same subject.  Of course, the engine needs to work a little harder each time you reference it, but that's why we keep feeding it...

Since this is beyond the scope of the TMRM and into the realm of what's specified by the TMDM legend, it just means that I can do it in my implementation using one mechanism and you (or anyone else) can do it in the TMDM the way you describe.  The actual amount of effort required to fix this kind of problem just might be different. :)

> [...]
>> 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.
> 
> Yes, detecting relative IRIs might be difficult / impossible.

Based on the fact of dealing with this problem in my implementation on a regular basis, I'm leaning heavily towards the latter.  I try and do some clever things to "do the right thing", but there are still times when there's no way (at least that I've come up with yet) for the parser to determine X should be interpreted as an identifier vs. a literal string.  I have some syntax rules that determine which side wins depending on the parsing context, but ultimately, I also have some syntactic sugar to say "this is a literal, damn it!" where required.

I would see this situation as having the same problem.

> [...]
>> 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... ;).
> 
> You need a good algorithm for that problem, yes. In XSLT I use
> "generate-id" and I bind the id to a variable or I ensure that I
> always use the same node to generate the id.

Agreed.  That's similar to what I do most of the time too, but I also have several types of normalization functions that are applied depending on the context in which the value is encountered so that I can *try* to generate stable proxy identifiers in a temporally independent manner and across parsing runs.

Of course, this doesn't always work and we're back to the Patrick Problem... ;)

> 
>> 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.
> [...]
> 
> Yes, this approach might be better than my approach since I create
> always a topic with a random item identifier which results in
> duplicates (the Patrick problem). You could also try to URL-encode the
> string and use that result as item identifier / identity. The downside
> is that all "John Does" would merge which might not be the desired
> result.


Yep.  That's the other problem with it.  Again, I try and resolve this based on applying what context I have available to differentiate between person1 and person2 if they have the same name (normally where I find them or the role they're playing, etc.), but there's always a limit to what context is available that actually doesn't get in the way when you encounter the same subject in a different context (the horror!).

I've been doing a lot of information gardening lately, so these issues are pretty fresh in my mind...

Cheers,

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