Re: Another round of subject identity crisis c.2011

[successfully remembering once again to hit reply-all...]

Hi Lars,

On 9 Mar 2011, at 8:40 PM, Lars Heuer wrote:

> Hi Andrew,
> 
> Now that we can assume that we have a common understanding of CTM,
> back to your e-mail :)
> 
> [...]
>> This isn't the type of example I was talking about, and yes, I agree
>> with you that the only way to do this is via PSI's and the normal
>> subject indicator model.
> 
> I see. Well, I haven't understood that you (ab)use CTM and subject
> identifiers/locators to describe something outside of TMDM. If I see
> something encoded in CTM/XTM my internal CTM/XTM processor maps that
> automatically to TMDM. While I wait for rev. 2 of my internal CTM/XTM
> processor I try to understand what your problem really is about.
> Unsure if I understood it, though. I should have read your reference
> [1] before giving an answer. :)

See, here I was trying to fit in....  While it rarely works for me in real life, I thought I might actually have a chance to do it here.... After all, this particular thought started from me trying to figure out how I could map my world view of Topic Maps to the CTM use cases (or not).  Abuse is probably right, although I do faithfully assert that no CTM instances were injured or otherwise placed in harm's way during the typing of these emails.  Is there a SPCTMN*?  Am I safe?

Anyway, sorry about the unintended dissonance...

> Regarding [1]: You state that x (a topic) is reified by y (a topic).
> In TMDM-country x and y are replaced by z which represents the all
> properties of x and y (since x and y represent the same
> subject/topic). What would happen in Andrew-country if someone says x
> reifies y? I assume that x and y are still different proxies. But
> which relationship does "reifies" create? Do you create a proxy z
> which represents the the union of x and y?

By default?  Very little.  An assertion is created saying that x reifies y and that's about it.  In the current implementation, it's simply a property of proxy x.  What you can do is either search based on reifier and take an application-defined action, or you can (and this is still considered alpha as far as the system goes) pass an option to the engine which will give you a transient proxy z which reflects the merging of the two, but which exists outside the scope of the given map.  Really, the same model applies both for subject locator based reification as well as subject indicator based subject identification, just with different semantics.

My rationale here is to by default preserve as much information as possible so that information can be consumed in context-dependent ways without undermining the integrity of the underlying map representation.  There's quite a bit more experimental things I plan to do with this approach down the line, but I haven't had much of an opportunity of late to play with it.

> I think that your definition of "reifies/reified by" is important to
> have common terminology since you use "reification" very often in your
> problem description.

I suppose that my definition of reification - while actually a blended view of [1] and [2] - really boils down to:

	reification is a semantically-endowed alias;

and

	both subject identifiers and subject locators are reification with different semantics;

implies

	aliasing without the implied merging of the TMDM is really just aliasing.

This is probably why the term has been derided a bit in some of the discussions here in the past, because it can be overloaded.  However, when I'm saying "reification" in the previous emails, it is really to " '[make] something a first-class citizen' within the scope of a particular system" [1].  Informal or not, that's my interpretation of subject locators as defined.  What they do is take a resource outside the closed system of a topic map instance and provide a semantically augmented alias for that resource so that it can be "made into a thing" [1] - in the case of TMDM a topic instance; for TMRM a proxy - and it can therefore participate within the closed system of the topic map.

As far as that goes, i.e. reification of an external resource via either a subject locator or a subject identifier, it creates an instance of the default "thing" in the system, e.g. a topic or proxy instance.  This semantic alias can thereby be used as a focal point for assertions made about the subject that exists outside the system.  Interpretation of that alias is dependent upon the syntax and the associated semantics implied by the syntax within the definition of the specification, e.g. "the topic *is* the resource" or "the topic represents the subject (primarily) described by the resource."

The two issues that overlap somewhat where I started this is the notion of the system being closed and being able to reify (as in "making a first-class citizen") information provided by that external resource in an even richer semantic sense, allowing you to do stuff as described in [2].  That's where my "reified as type" concept came from in one of the previous mails, and that's really the scenario I'm describing when I want to import/include the "foreign" resource into the map in a particular manner.

So, that means that if I do something like (WARNING: NOTATIONAL SWITCH IMMINENT):

	# ATM (based on AsTMa= 1.3) - No, the "A" isn't for "Andrew" either...
	# I'm lazy and not interested in qualifying the type
	topic reifies http://www.topicmaps.org/xtm/1.0/core.xtm#topic

In "Andrew's world", this says the same thing you'd expect in TMDM.  I've created an item identifier for a topic (proxy) representing the external resource.  However, conceptually (again, in Andrew's world--cue scary music), if I then do this:

	t1 (topic)

Then I've implicitly typed the reification above and said that my intention - as the author of the map - is to impart upon the item identifier topic all of the characteristics of http://www.topicmaps.org/xtm/1.0/core.xtm#topic IFF I can:

	a) resolve the URI http://www.topicmaps.org/xtm/1.0/core.xtm#topic, and
	b) process the resource - possibly via a transformation - as something that can be interpreted as a topic (or proxy) which, by definition, can be used as a type,

THEN

	I have imported the characteristics of the remote resource into the local map in a semantically rich way AS IF I had defined said resource locally in the first place.  I don't have to assign additional characteristics in the way I would if I had referenced the resource as a subject identifier, because, by definition subject identifiers are opaque.

For completeness and in line with the second scenario, you could make the same assertion all in one go:

	# typed reification all at once
	topic (type) reifies http://www.topicmaps.org/xtm/1.0/core.xtm#topic

Also for completeness note that the following IS NOT equivalent because while http://www.topicmaps.org/xtm/1.0/core.xtm#topic is defined as a topic in XTM, http://psi.topicmaps.org/iso13250/glossary/topic actually is not, nor does it offer any discoverability of a suitable representation.  It is simply a PSI.

	# Won't do anything more than standard TMDM-style subject locator based reification
	# and is of questionable value--unless you're going to describe the PSI representation
	# itself
	topic reifies http://psi.topicmaps.org/iso13250/glossary/topic 

	# In this case the only choice is to use http://psi.topicmaps.org/iso13250/glossary/topic
	# as a subject identifier as per TMDM
	topic
	si: http://psi.topicmaps.org/iso13250/glossary/topic 

The rational I have for formalizing this is fully in line with being able to follow the definition of reification in [2]: that "reification" is necessary to make assertions about the informational content obtained from a particular source without getting entangled in the truth or falsehood of those statements.

I know some of the early TM literature attempted to address problem with scopes, but I thought that was even more convoluted than what I'm describing.  Personal taste, perhaps...

To me reification of remote, first-class citizens in every way other than that they happen to be remote is a degenerate form of the more controversial example I used before of creating a proxy which represents information assertions obtained from the resource.  The difference in the more complex case is that you're asserting reification as a type other than what you might initially expect.  With the case of reifying remote topic map constructs with all their characteristics, you're logical assumption is that they bring all their typing and semantics as well.  With reification to create a proxy that is a type other than the default/expected one for the resource, you're explicitly stating the nature of that reification in effectively a controlled, yet extensible and application-defined way.

"Lucy says Andrew is a person" isn't far from "http://atownley.org/about says Andrew is a person" (easy), and it isn't really all that far from saying "http://en.wikipedia.org/wiki/County_Dublin says Dublin is a county" and "http://en.wikipedia.org/wiki/Dublin says Dublin is a city and the capital of Ireland."  On their own, these can all be handled by using the URIs as subject indicators.

However, when you actually care about discussing the specific assertions made about a particular subject by a particular (re)source, that's where "reifies as type" comes in.  You're making an explicit link between the resource making the assertions, the type of the subject to which those assertions relate and the identifier (semantic alias) used to denote the particular proxy that binds all these things together.  For good measure, you could go ahead and assign a subject identifier so that you are sure to not be confused as to what subject the statements made by the proxy reified by the resource using a subject locator.

Admittedly, this introduces some complexity into the binary TMDM identity model of locators vs. identifiers, but I think it's regular enough and with precedence rules to govern interpretation of which of the subjects refers to which aspects of the relationship, it is manageable complexity.  You could do it with an association or dedicated proxy type, but, from my experience anyway, as soon as you hit a certain volume of information about a subject (or set of subjects), things get messy, contradictory and sometimes downright ugly--yet you still need a way to manage this complexity.

I feel that this inherent complexity is so intertwined with information management that it should be expressible as built-in constructions to topic maps.  Naturally, there might be better ways to do it, however both of the scenarios I describe are things I deal with every day right now, and have been dealing with them nearly every day for the last 7-8 months.

> [...]
>> If I wanted to talk about a proxy that reifies an image of Dublin,
>> who defines the rules by which the type and properties are
>> determined?  This picture is from 1942 and this one is from 2011 of
>> the same street.  There has to be a way to reference a collection of
>> properties about a subject (so maybe I should've included
>> <http://.../Dublin> as well) and tie those efficiently to the
>> resource from which they were derived.
> 
> You'd define an ontology/a legend which tells you that it's the same
> street at the moment t1 and at the moment t2. Probably you wouldn't
> have to state that: Simply use the IRI of of picture A and the IRI of
> picture B and make statements about it. Someone may recognize that pic
> A and B represent the same street and either merge the proxies/topics
> since they represent the same street or create another
> proxy/association between them. It depends on your individual world
> view.

Using the mechanism above, you could do this kind of thing:

	mainst (street)
	si: IRI-for-main-st
	name: Main St.

	t1 (street) reifies ...picA
	length: 20km
	si: mainst

	picA reifies ...picA
	taken: 1942

	t2 (street) reifies ...picB
	length: 100km
	si: mainst

	picB reifies ..picB
	taken: 2011

> If I take a picture of a house you walk by mistake into the scene, I
> wouldn't care about you, publish my picture and use the IRI to state
> "I talk about the subject 'house' depicted at IRI XY". Someone sees
> you at the picture and says "I talk about the person 'Andrew' depicted
> at IRI XY". It's a matter of trust/context to identify the concrete
> subject and I doubt that Topic Maps or other any technology can
> resolve this conflict. It depends on your perspective. In TMDM-country
> this may become a problem since a Topic Maps engine would blindly
> merge the subject identifier XY and we don't have a a (standardized)
> unmerge operation. Other, fine-grained technologies may avoid the
> merge and create a dynamic/user-dependent view on the subject.
> 
> A possible solution of this conflict are PSIs which are meant to
> describe a subject uniquely. If we wouldn't take the picture but your
> e-mail address to identify you and a geo pos to describe the house,
> and create relationships to the same picture (also a topic/proxy),
> we'd avoid accidental merging operations to some extent.

In the above example, you would indeed end up with a mess.  However, without the reification and the typing aspects, you can easily find just as many examples where TMDM is going to give you a mess simply because, as you state, different world views were used to author the source maps.  In this respect, TMDM merging certainly shares the binary nature of pregnancy.  There is no "kinda merged" just like there is no "kinda pregnant"...

> ... another long mail without solving your problem? :)

;) kinda... "A" for effort, though! :)

> [1]
> <http://www.infoloom.com/pipermail/topicmapmail/2010q4/008728.html>


* Society for the Prevention of Cruelty to Topic Map Notations
[1] http://en.wikipedia.org/wiki/Reification_(computer_science)
[2] http://en.wikipedia.org/wiki/Reification_(knowledge_representation)
--
Andrew S. Townley <[email protected]>
http://atownley.org