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

Hi Lars,

On 6 Oct 2010, at 6:19 PM, Lars Heuer wrote:
> 
>> 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.
> 
> I see. Basically, your is-reified-by proxy seems to be the same as the
> owl:sameAs property, right?

Not as I understand owl:sameAs.  If proxy1 and proxy2 have different properties or different values for the same property and both reify proxy3, then that means that if you access proxy1, then you trigger a merge of proxy1 and anything else that also reifies proxy3 (that we know about).  What doesn't happen is that proxy1 and proxy3 or proxy2 and proxy3 merge.  The net effect is that proxy1 and proxy2 become aliases for each other, but there's still a distinct semantic relationship between proxy1 or proxy2  and proxy3.

Given that proxy1 and proxy2 are merged and both proxies reify the third, therefore they represent the same subject.  I'd say that proxy1 owl:sameAs proxy2 would then apply, but with the additional constraints of "sameness" defined by reification according to the topic maps specifications.

That's why I said that it's effectively the same type of thing you can do with the TMDM, but you just use the single construct to do it with what I have.  You still have to have a 3rd "hook" on which to hang everything else--it's just that it can be a "normal" proxy rather than an explicitly external identifier.

>> 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
> 
> A neat side effect of your approach: You can simply "unmerge" proxies
> if you remove the is-reified-by relationship between two proxies while
> unmerging topics is much more difficult (and often impossible). The
> downside is the bigger amount of proxies an engine has to cope with.

Actually, that's by design... ;)

It's also one of the biggest reasons I ended up mostly ignoring the TMDM and basing my work on the TMRM.  The implied and explicit notion of "merge the world into my universe" didn't exactly appeal to me based on the problems I'm trying to solve.  I'd have to have a system capable of storing the whole Internet (and then some), and such a system is a tad beyond my budgetary constraints--even if it was possible to build.  Even Google has limits. :)

Dealing with a large number of proxies was also one of the design constraints for the engine, so we're generally good on that front too.  Although, like many things, the performance of certain operations could always be improved a bit...here and there... ;)

> [...]
>> 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.
> [...]
> 
> We're having the same set of problems :)


Then I'm very keen on exploring some common solutions that might help us both!

Thanks for the discussion today.

Cheers,

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