Re: MARCXML to Topic Maps implementation!

Lars,

A question of terminology below:

On 7/21/2010 5:43 AM, Lars Heuer wrote:
> Hi Aki,
>
> I uploaded your topic map to Maiana:
> <http://maiana.topicmapslab.de/u/lars/tm/marc-tm-akis-example>
> (using your
> <http://www.wandora.org/wandora/download/other/marc2topicmap_example.zip>)
>
>
> [MARCXML ->  Topic Maps]
>    
>> When a record is found
>>     Create a topic for the record
>>     For each field in the record
>>        Create an association where association type is field code
>>        For each subfield
>>           Create a role topic using subfield code
>>           Create a player topic using subfield value
>>           Add created player and role to the association
>>        If a field has an indicator
>>           Add it to the association as a player with a static role
>>      
>    
>> Simple as that.
>>      
> I know that this is meant as prototype but I think without a proper
> ontology this translation makes not much sense. You put MARCXML into a
> a Topic Maps envelope and that's it.
>    
When you say *proper ontology* do you mean:

1) a series of subjects that define types and relationships between 
subjects that appear in the topic map, or

2) greater definition of the subjects that appear in the topic map 
themselves, or

3) some combination of #1 and #2?

To be sure, we need to know more about the subjects that appear as 
"field codes" and "subfield codes" but as I may have said in an earlier 
post or on my blog, topic maps should be viewed as *resources that can 
be refined."

And not necessarily by the same person. I am sure there are librarians 
who know more about some field or subfield codes than others. Once a set 
of MARC records are in a "Topic Maps envelope" as you put it, a number 
of things become possible.

One is that other people can start adding information for merging into 
the topic map to further identify the subjects that appear in the map.

I suspect the ontology types, with their various class distinctions 
won't be far behind. ;-)

Hope you are having a great day!

Patrick

PS: I like the association approach for fields and subfields. Even with 
improvements that I would like to see to the TMDM with regard to 
properties of topics, in general I prefer the use of associations for 
properties. More verbose/explicit depending on how you want to 
characterize it. Arguments go either way and the choice in a particular 
circumstance is requirement driven.

PPS: Think of the difference between viewing a MARC record at the 
Library of Congress and what Aki has done. If you know what a MARC field 
code means or have a suggestion for what could be added to it to make it 
meaningful to me, for example, what do you do? Write to the Library of 
Congress and ask them to add the information so that it appears with 
that MARC field value? I won't discourage you but on the other hand I 
won't wait for it to appear.

If you have Aki's conversion to a topic map and you want to add that 
information, assuming the field value appears as a topic in the map (or 
you can add it as a topic in the map), then you create your "addition" 
to the map and merge it with the topic map that Aki created.

Aki is free to merge or not your addition but the important thing is 
that the topic map is not bound to its original construction. Try that 
with a "static" information system.



> I suspect that the topic map provides any advantage over the MARCXML
> records.
>
> Don't get me wrong, I back your effort and I think it is good to see
> that someone does actually something, but the advantages of Topic Maps
> remain unclear if you translate MARCXML literally to Topic Maps.
>
> Best regards,
> Lars
>    

-- 
Patrick Durusau
patrick-Q/[email protected]
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau