Re: XML, Topic Maps and Everything (was Re: [xml-dev] Relationships [was RE: James Clark: XML versus the Web]

Hi Jan,

On 8 Dec 2010, at 9:18 AM, Jan Schreiber wrote:

> Hi Andrew,
> 
> thanks for your great post! I've done some work with TMRM earlier, so this was very interesting.

Thanks.  I'm glad it made sense.  Not always a foregone conclusion when writing emails at 3AM! :)

>> <snip>
>> Each label is a symbol referencing another Subject Proxy, and all you need to do to declare a Subject Proxy is reference it.
> 
> I never got that right. Where does TMRM say that a reference to a proxy is enough to declare a proxy? For some reasons, I always thought that I only can use declared proxies as property values... This works fine until you try to interpret the result of some path expressions as a subject map.

Yeah, that would be a problem.  The lazy resolution and recursive nature of the TMRM depend on definition as you go, as far as I'm concerned.  Doing it another way doesn't mean you don't have a TMRM-based system per se (you could always provide a restrictive legend), but it wouldn't be where I would start.

>> <snip>
>> For example, you could represent the TMRM specification itself very simply in JSON as:
> 
> Cool. My libtmrm [1] (early alpha and probably no longer maintained) used YAML to import and export subject maps.

YAML was another thing I could've mentioned in the post, but I didn't want to bring in the world as JSON was the main alternative to XML discussed in the original thread.  YAML makes more sense to me than JSON because of the references.

> I put a lot of effort in libtmrm to limit the number of proxies referenced in my ledgend. In the YAML import, there is only one "magic" proxy, libtmrm_bottom which is used for bootstrapping. Based on this proxy, I defined a little bootstrap-ontology that gives me type, instance, superclass and subclass proxies and some metainformation about the bootstrap ontology:
> 
> ---
> subject_map: 'bootstrap'
> proxies:
>    libtmrm_bottom: {libtmrm_bottom: libtmrm_bottom}
>    ontology: {libtmrm_bottom: 'libtmrm:ontology'}
>    ontology_version_major: {libtmrm_bottom: 'libtmrm:ontology-version-major'}
>    ontology_version_minor: {libtmrm_bottom: 'libtmrm:ontology-version-minor'}
>    bootstrap:
>        ontology: 'bootstrap'
>        ontology_version_major: 0
>        ontology_version_minor: 1
>    superclass: {libtmrm_bottom: 'libtmrm:superclass'}
>    subclass: {libtmrm_bottom: 'libtmrm:subclass'}
>    type: {libtmrm_bottom: 'libtmrm:type'}
>    instance: {libtmrm_bottom: 'libtmrm:instance'}
> ...
> 
> Every time you create a new subject map, this boot strap ontology is automatically imported. libtmrm caches the proxies for superclass, subclass, type and instance and uses them as part of the path expressions. Internally, labels are just integers (or they could even be memory addresses if the subject map was kept in memory). Libtmrm uses the bootstrap-proxy and the literal values e.g. 'libtmrm:superclass' to query for the subclass proxy. The bootstrap proxy always has the internal label 0. Otherwise there are no special proxies known to the library. 
> 
> I'm not sure if this makes sense anymore, it's probably not the right way to go. Declaring a proxy by referencing it would change a lot...


Very interesting.  I think I have about 5-6 bootstrap labels/proxy identifiers, but some of those implement the isa and sub relations.  The rest of the system is expressed in terms of higher level  constructs built on those fundamentals.

Thanks for the reminder of libtmrm.

Cheers,

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