Re: TM/JSON first draft

Hi Lars,

Thanks for your feedback.

Am 17.08.2010 um 17:44 schrieb Lars Heuer:

> [...]
>> http://www.cerny-online.com/tmjson/
>
> Thanks for posting it. I have to admit that I don't see the advantage
> of TM/JSON above JTM yet. The last footnote in the document gives the
> impression that you want to use it as poor man's TMQL.

The advantage that TM/JSON over JTM has is the same advantage that TM/ 
XML has over XTM: code which processes the TM/XML (e.g. XSLT)  
actually deals with tag names that are from the domain vocabulary  
which is what most programmers are used to. Now if you take that the  
leap from XML to JSON, you have on the hand processing via JsonT  
(similar to XSLT) and jsonpath (XPATH). On the other hand you can  
simply deserialize the document in you favorite programming language  
and deal for the largest part with domain vocabulary rather than some  
abstraction  (Topic Maps).

So the typical use case would be:

1) Fetch a TM/JSON document and decode it via json decode
2) Access and/or manipulate the document using something that looks  
like a domain object not like a topic map
3) Possibly json encode the data structure and save the updated TM/ 
JSON document back

All this does should not involve any Topic Maps aware software (not  
counting the data source) or programmer.

> Anyway, a few comments:
> * Requiring the topic id (again) is IMO wrong. I am happy that neither
>   TM/XML 1.1, JTM 1.0, XTM 2.1, nor CTM mandates a topic identifier.
>   If a topic has just a subject identifier, the serializer has to
>   generate a topic id which is error prone and results into a topic
>   map which represents not a 1:1 mapping of the original data model.

An id attribute needs two seconds of explanation while detailed  
knowledge of subject identity requires much more time and is an  
overkill for most cases. The format is supposed to work without a  
Topic Maps engine in any programming language that supports JSON (see  
http://www.json.org for a list). Whether stateless parsing of the  
document is possible is in this case secondary.

> * It's unclear to me why the keys have sometimes a meaning (i.e.
>   "movie" or "person" which indicates the type of a topic) and
>   sometimes not (like "publication-year" which represents not the type
>   of the occurrence). In the latter case, the key defines simply a
>   container for an occurrence or a name.

Actually "publication-year" is pretty meaningful in my book.  
Accessing the value is easy in JavaScript e.g. tm.movie["publication- 
year"].value. The reason that the whole occurrence is there that  
deserialization into a topic map is easy and context free (opposite  
to TM/XML which relies on a tagname to type mapping). Yet, it is  
still simple for the Topic Maps unaware programmer to ignore other  
members given that those members are also unlikely to occur in the  
program. But i am open to any suggestions which simplify the format  
but still maintain all other properties. Trade-off discussions are  
also welcome.

> Further, I find TM/JSON too verbose and it remains unclear why
> "readability of the document" is a design constraint. I cannot imagine
> that humans would encode their topic maps in TM/JSON because they have
> to repeat the associations at each role player. And for machines, the
> name of the name / occurrence "containers" (like "publication-year")
> is unimportant.

It can be authored by humans, but it is not what it is made for. It  
is more likely that an existing document is parsed, then the  
structure is altered or augmented, then json encoded and sent back.  
TM/JSON also attaches any JSON aware programming language to a  
service that provides TM/JSON documents and accepts TM/JSON  
writebacks. The only other thing necessary is a XML Schem datatype  
decoder and encoder.

I hope these explanations make the agenda more transparent and sorry  
for being unclear in the first place. I will update the specification  
to include some of the information presented here.

Best regards,

Robert Cerny