Re: Another round of subject identity crisis c.2011

Hi Lars,

On 9 Mar 2011, at 9:37 AM, Lars Heuer wrote:

> Hi Andrew,
> 
> [...]
>> understanding of the difference in most cases between subject
>> indicators and subject locators (seemingly "old terminology"
>> though),
> [...]
> 
> The term "subject indicator" still exists. The subject indicator is
> the resource while the subject identifier is an IRI which refers to
> the subject indicator: A PSI is a published subject *indicator*, the
> reference to PSI by a topic is a subject identifier.

Right.  That makes sense.  I just didn't have sufficient google-fu, apparently.  Thanks.

>> I must say I was slightly confused to see that the general
>> consensus is that PSI references  seem to only be used as subject
>> indic^H^H^H^Hdentifiers and never as subject locators.
> 
> PSIs can be used as subject locators but that implies that you make
> statements about the resource and not about subject the indicator was
> published for. I use this distinction for the PSI template [1] (usage:
> [2]). The resource is a topic map (TM/XML encoded) and the IRI of the
> resource is used as subject locator to assign statements like author,
> created at, modified at, status etc. If you're not familiar with
> TM/XML, here a short translation to CTM (prefixes and template
> definitions omitted):
> 
>     http://psi.example.org/thing
>         - "Thing";
>         dc:description: "bla bla"
>     .
> 
>     = http://psi.example.org/thing
>         created-by(Joe-Doe);
>         status(psi:experimental);
>         created-at(2011-03-09);
>         modified-at(2011-03-09);
>     .
> 
> The subject locator is used to attach metadata to the PSI.

Hmmm.... I understand what you're saying, but I'm not sure I get it.  Maybe it's just personal perspective warpage going on here, but in this case, why is the extra level of redirection necessary?  This is probably old ground, but why wouldn't you just put the metadata on the thing itself ant treat the thing as a topic?

Where does the rubber meet the road in terms of "topics are representations of subjects, but some subjects are topics" and how these are managed?  I see no difference in reifying a topic in a local map using a subject locator and reifying a topic that happens to be a network-addressable resource, so long as you can interpret said resource as intended.

Normal usage for me, for example, is to provide type-based groupings of metadata about a resource (which is why I included a reference to my previous discussion).  For example - and please forgive any CTMism mistakes - if I want to talk about the generic HTTP metadata of a resource, I do something like this:

MYLOCID = http://example.org/random/page.html
	isa webpage;
	[PROPERTIES FROM HTTP RESPONSE] .

If I want to make type-based statements about the content from said resource, I do something like this:

dublin = http://en.wikipedia.org/wiki/Dublin
	isa city;
	population: 506211;
	... ;
	.

What you're effectively saying above is that there's no way to publish networked topic maps, right?  If both locators and identifiers are treated as opaque, this must be true.

I guess since I take a networked view of the world, to me, identifiers can't be anything but opaque, but locators, since they by definition are intended to be used to identify subjects which are the resource in question, must not be opaque.  You can't actually deal with subjects, they're only shadows, so you need a proxy for that subject, e.g. TMRM proxy or TMDM topic that you can actually touch.

Therefore, if subject locators are addressable, and, by definition, they're subjects - but only until the address resolution takes place.  Once you have this, you have a "something".  In my view, the only way networked topic maps will work is if you can attempt to introspect that something, at some level, and, where possible, do something useful with it.  Maybe that is governed by the local type you choose, e.g.

= http://psi.example.org/v1/mytype isa TYPEPSI .

but maybe it isn't.  I can actually see arguments both ways, but they all boil down to time of resolution, e.g. lazy load vs. preload.

> 
> [...]
>>        mytype = http://psi.myco.com/v1/mytype .
> 
>> What have I done?
> 
> You've assigned a subject locator to your local identifier "mytype".
> That's all. :)

What about the above, or even this:

t1 isa =http://psi.example.org/v1/mytype .

is that legal?

>> In my view, what I've done is pulled in the type definition defined
>> externally into the local map so that the semantics intended by the
>> published topic instance that declares the type 'mytype' don't have
>> to be repeated while at the same time explicitly indicating that the
>> ontology of the current map is tied to the external resource defined
>> by the subject locator.
> 
> No, nothing is pulled into your topic map. Your topic map knows
> nothing about the ontology at <http://psi.myco.com/v1/mytype>. You
> wouldn't pull the HTML into into your topic map if you refer to
> http://www.example.org/blog-post.html. You simply state that you'll
> make statements about the referenced resource.

Granted that's a tooling decision, but it could arguably be core if something like the context of use was evaluated to determine the intention of your use of said resource.  If you say you're going to use it as a type, then the engine could attempt to resolve it as such.  If it couldn't (server down, typo, 404 error message HTML, etc., then it could quite reasonably be expected to throw an error.  This is part of the price of a networked model.

I could quite easily make said decision based on the content type or even the context of use--even indirectly (as per previous example):

mytype = http://psi.example.org/v1/mytype.
t1 isa mytype.

mytype is clearly being used as a type, regardless of how it is declared, but if we pulled the string a little to unravel/introspect mytype, again, we could dereference it as effectively a local alias for a remote resource that happens to be a first-class topic map entity.

> [...]
>> What are the pitfalls of using a subject locator IF:
> 
>> 1) I've made every effort to define the resource in a
>> machine-friendly format processable by topic map implementations, and
> 
>> 2) I've made every effort to ensure that said resource is served in
>> a way that would provide all possible meta-data to indicate that
>> this resource WAS a valid topic maps construct rather than any
>> arbitrary, untyped resource which could be retrieved from that location.
> 
> I'd think that should be application-specific and not solved at the
> Topic Maps level. Although I wouldn't use the IRIs of the PSIs at the
> application-level for subject locators but I'd try to issue a GET
> request to resource in the hope that I get more information about the
> subject represented by the *indicator* (i.e. the name and the
> description and maybe LOD-alike links to other PSIs). The chance that
> you get more information about a resource which was meant to be
> consumed by RDF/Topic Maps applications is bigger than trying to
> resolve a subject locator and hope that it isn't a bloody HTML page
> but something more useful (RDFa may change that, though).
> 
> [...]

I agree with you that in the "standard, centralized, pull-everything-to-me" mode of thinking, that's true.  However, as I mentioned, I view it as more of a local garden with a bit of a fence vs. a wall that can be augmented with topic maps constructs that just happen to be sitting on the network.  This view admittedly isn't part of my core TMRM constructs, but it is implemented by the layer that sits just above it.

The architecture I have is really a "network by default" model vs. a "closed world" model.  What it does to manage that under the covers is a different matter, but to the user of the topic map(s) hosted by the system, it all "feels" local.  Having things like type definitions, ontologies and even entire information sets distributed is a core part of the system, so I'm trying to figure out the best, least incompatible way to bridge the two world views without introducing either new terminology, keywords or the like wherever possible.

>> BTW, has this always been a google group?  I think this is the
>> first time I've ever seen an archived post show up there.
> 
> No, it's a mirror created by Benjamin Bock. The official archive is at
> <http://www.infoloom.com/pipermail/topicmapmail/>.

No wonder it showed up first in the search results! :)

Thanks for your thoughts.

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