Subject identity, reification and contexts through typing

Hi folks.  Me again...

Interested in any thoughts/feedback on the following.  I've been using things this way without actually formalizing it, and when I came to trying to explain it, I realized I was actually potentially mixing two different metaphors.  However, I think I have a get out clause that allows it to still all fit together in a coherent model. ;)

I'd be curious how people represent this using standard TMDM, but I also want to throw out my thinking in a more open-ended manner to elicit any flames, feedback or constructive criticism.  I don't claim that this is fully baked, but, in my own warped mind, it makes a lot of sense.

Given the following scenario:

  Article A is a publicly addressable Web resource R discussing concept C.

  Article B is a publicly addressable Web resource Q also discussing concept C.

  Article A asserts the statement S = 1

  Article B asserts the statement S = 2

  S is a characteristic of concept C

Making it easy, let's say that someone's helpfully published a PSI for concept C as resource I.

In my world, I can create the following proxies.  Hopefully the notation isn't a big deal as it's a streamlined version of AsTMa= v1.3.  I don't know CTM yet, and I never really learned any of the older syntaxes.  The "si" role assigns a subject indicator.  The "reifies" keyword is the same as AsTMa= v1.3, and the rest of the names identify property roles (labels) that have either literal or label values.  Labels can't have spaces, nor can they start with a digit.

p1 (webpage) reifies R
title: Article A
content-length: 12345
last-modified: Fri, 03 Dec 2010 18:43:45 GMT

p2 (webpage) reifies Q
title: Article B
content-length: 4567
last-modified: Fri, 03 Dec 2010 18:48:52 GMT

p3 (concept) reifies R
s: 1
si: I

p4 (concept) reifies Q
s: 2
si: I

Now, if I wanted to merge these, I might end up with this (doing a TMDM-ish merge):

p5 (concept)
s: 1
s: 2
si: I

Correct me if I'm wrong, but this means I've lost all of the context of the property characteristic 's', correct?

The way merging can happen for me is to end up with this:

p5 (concept)
@p3 s: 1
@p4 s: 2
si: I

For proxy p5, you can either choose to include or ignore the scope values, depending on what it is you're trying to say or what question you're trying to answer.  The decision is up to the agent interpreting proxy p5.  Alternatively, if the agent wanted to find all proxies that had the same subject indicator, they can request those and do their own interpretation, comparison or merging.  Likewise, they can also find all the proxies claiming to reify the same resource.

To me the typed reification tells you which particular set of properties matter and gives you an additional axis of context.  You may care more about the physical attributes of the resource (proxy p1 and proxy p2), but I may care much more about what the external resource is saying about the concept C (proxy p3 and proxy p4).

Here's where I'm not sure my outlook matches everyone else's, because, to me, both are reifying the resource in question in very different and specific ways that are very important.  Proxy instances are representations of a particular subject, whether they're reified or not.  Reification just provides additional providence as to where the information came from, and the proxy type provides you with concrete information on the "how" of the reification itself.

I've done some digging with Google for other takes on coherently representing the above with topic maps, but I haven't seen all that much on reification and how it relates to subject identity.  I haven't dug through every paper I have on my computer nor every book on my shelf, so it's highly likely I've missed something.

Based on the problems I'm trying to solve, this approach to layering context and preserving providence information and traceability for individual assertions "works in the lab", but I'd like to know if others have been around this tree and rejected it before.  If so, I'd like to understand why so I can either change my approach before it's too late, or that I can try and figure out a way to solve the problem triggering previous rejections of this approach.

At this stage, I don't care if you use TMDM, XTM or TMRM in your feedback because I'm more concerned about the approach than the representations.  I can do whatever mapping is required to get it into my system once I know whether if (and how) I need to change my approach.

Thanks in advance,

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