Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

November 9, 2010

Whose Logic Binds A Topic Map?

Filed under: Authoring Topic Maps,Semantic Web,TMDM,TMRM,Topic Maps — Patrick Durusau @ 7:15 am

An exchange with Lars Heuer over what the TMRM should say about “ako” and “isa” (see: A Guide to Publishing Linked Data Without Redirects brings up an important but often unspoken issue.

The current draft of the Topic Maps Reference Model (TMRM) says that subclass-superclass relationships are reflexive and transitive. Moreover, “isa” relationships, are non-reflexive and transitive.

Which is all well and good, assuming that accords with your definition of subclass-superclass and isa. The Topic Maps Data Model (TMDM) on the other hand defines “isa” as non-transitive.

Either one is a legitimate choice and I will cover the resolution of that difference elsewhere.

My point here is to ask: “Whose logic binds a topic map?”

My impression is that here and in the Semantic Web, logical frameworks are being created, into which users are supposed to fit their data.

As a user I would take serious exception to fitting my data into someone else’s world view (read logic).

That the real question isn’t it?

Whether IT/SW dictates to users the logic that will bind their data or if users get to define their own “logics?”

Given the popularity of tagging and folksonomies, user “logics” look like the better bet.

6 Comments

  1. While a move to a more semantically linked web is inevitable – I also think we’re moving towards a more personal experience.

    Personal preference seems to be driving marketing (via behavioural profiling), which I personally feel is shady; however it does suggest a trend towards receiving information that has been arranged according to the users personal needs.

    I think that any semantic arrangement of data would most definitely need to take account of each person’s individual world-view.

    The beauty of tagging and folksonomies is in its simplicity and adaptability. I think one problem with TMRM is that it seems quite complicated.

    Comment by Luke — November 9, 2010 @ 9:21 am

  2. Luke,

    On the TMRM, I could suggest you look back at one of the 50+ page versions for complicated. 😉

    Actually the TMRM, aside from the path language, is quite simple, but simplicity is difficult to state clearly.

    While tagging and folksonomies are simple and adaptable, they are not reliably interchangeable. That is an issue that the TMRM addresses with legends.

    I will do a series of post on the practicalities of legends.

    Comment by Patrick Durusau — November 9, 2010 @ 9:40 am

  3. Is the definition of “isa” and “sub”/”ako” an issue? If the definition does not fit, you may create “my-isa” and “my-ako” proxies which fit to your model.
    I am not that deep in TMRM anymore, but I guess the definition of isa and sub is necessary, at least for the path language.

    Comment by Lars — November 9, 2010 @ 12:44 pm

  4. Yes, the defined isa and sub are necessary for the path language but it is only one path language among many possible path languages.

    Personally I think it is a very good path language but opinions vary and simpler path languages are certainly possible.

    If you think of the TMRM as saying that all subject proxies are composed of key/value pairs, that keys are references to proxies that define the keys (and consequently the value that a key may have) and that values may be proxies, you have the TMRM in a nutshell.

    It is the silence in mapping that defeats re-use of the results of semantic integration. If I were to map the key SSN to employeeID, that might work as a mapping between two data sources for me, but it is unlikely it would work for you.

    If under the rhetoric of the TMRM, I say, “Hey! Give me a proxy that represent the subjects signaled by SSN and employeeID” and its legend. Then you will have key/value pairs and a merging rule. That I can look at and decide if I have the same subject in my topic map or not.

    None of the means that you have to keep recursively defining representatives for subjects, just that you need to define them as far as is useful for you. That is the critical language, “…as far as is useful for you.”

    There is no prior requirement or limitation.

    Comment by Patrick Durusau — November 9, 2010 @ 1:39 pm

  5. Hi Patrick,

    So, I *did* read one or two of your blog posts, but only accidentally… 😉

    I think the two most important parts of the above discussion in relation to the TMRM and even the context of any assertion within a Subject/Topic map are:

    1: “If you think of the TMRM as saying that all subject proxies are composed of key/value pairs, that keys are references to proxies that define the keys (and consequently the value that a key may have) and that values may be proxies, you have the TMRM in a nutshell.”

    and

    2: “you [just] need to define [subject proxies] as far as is useful for you”

    which actually leaves you with one of the things that I’ve found most liberating and useful: simply including an identifier within your map defines it within that scope, and many times, that alone can be “useful enough” as a starting point that you can later revisit, decorate with more properties and then “grow” that arbitrary string – with no magic about it other than the way it is used – into something that says interesting and meaningful things within the scope of the map itself.

    Thanks also for flagging the difference between interpretation of “isa” between TMDM and TMRM. I hadn’t noticed that before.

    Agree with you 100% on the “this is what my data means to me” perspective of most users, and here we go around the whole context definition circle again.

    Great post and great questions, Patrick!

    Thanks,

    ast

    Comment by Andrew S. Townley — November 10, 2010 @ 7:26 pm

  6. Andrew: Thank goodness over the Internet no one can see you blushing!

    Glad you liked it.

    Hope you are having a great day!

    Patrick

    Comment by Patrick Durusau — November 10, 2010 @ 9:59 pm

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress