make viaf [and other] ids clickable --> external link

[jodevelops]

Screenshot: the yellow marked number (viaf-id) should be clickable, leads to the single view of the viaf id (links for this example below) on viaf.org

http://viaf.org/viaf/307435904/#Colo%CC%81quio_Internacional_Marx_e_Engels_%286th_:_2009_:_Campinas,_Sa%CC%83o_Paulo,_Brazil%29 or: http://viaf.org/viaf/307435904/

[zwobit]

How about adding the links into the @href attribute?

[MatthiasArnold]

hm. is this not redundant? the link to the viaf service http://viaf.org/viaf/ should be persistent. can the refid attribute, which is displayed in the editor, be linked to this service?

[jodevelops]

i don't really see a conflict or redundance here, because the href or refid can be excluded from display.

Why not store the SPECIFIC viaf link to a specific record as the href attribute within the main element ("name") and then (in the display), refer to that link, when (anything) needs to be clickable?

[ChiSamurai]

I would prefer not to use a "static" link in @href. Imo a better way to go would be to define such urls like http://viaf.org/viaf/$id somewhere in a configuration file and dynamically generate that uri. Despite it probably will stay persistent for viaf and others there could be some "instable" urls for other services which should be resolved/composited the same way. If an uri changes, the internal update would be much more easy and reliable with a kind of configuration file.

[jodevelops]

I am not sure, whether or not terms like "specific", "persistent" and "static" are dangerously confused here or what exactly "persistent" means, but I would like to support @ChiSamurai 's solution here.

The integration of the link is a powerful little feature, that can be used in many ways - and as shown above, its dynamic construction seems to be not too complicated.

[jodevelops]

Maybe in the beginning, this is what we will have to deal with, but lateron, that display can become more advanced.

[MatthiasArnold]

I think there is some confusion. ID (number) and repository (string) are both recorded in the XML. The ID is displayed in the editor, together with all the other attributes. This ID should be a link to the record in the respective repository (e.g. VIAF, AAT).

We need a mechanism that uses @refID and @vocab to generate the link. This may require some config file where the (however persistent) "base links" to all repositories we reference are stored, e.g. http://viaf.org/viaf/. So if vocab="viaf" then create a URL from "base link" and "refD": http://viaf.org/viaf/307435904/. I do not think we need to add a link in @href.

I think, this is exactly what @ChiSamurai suggests. Let's do it this way!

[jodevelops]

And where will the newly constructed links to the repository (such as http://viaf.org/viaf/109312616) be stored, when a record is saved?

Don't we need a place to keep the link or will all the links be created dynamically 'on the fly' as soon as the interface is loaded - running the 'contruct-link-script' everytime when loading Ziziphus?

IF we need this place, I guess @href is the right place, as Tobi suggested and the agent looks like that, when adding Václav Havel:

<agentSet>
<display/>
<notes/>
<agent dataDate="2014-12-10-11-02-15" pref="false">
    <attribution/>
    <culture/>
    <dates type="life">
        <earliestDate circa="false" type="">1936</earliestDate>
        <latestDate circa="false" type="">2011</latestDate>
    </dates>
    <name href="http://viaf.org/viaf/109312616" refid="109312616" source="viaf" type="personal" vocab="viaf">Havel, Václav</name>
    <role type="code" vocab="marcrelator">col</role>
</agent>

[MatthiasArnold]

With a service as described by @ChiSamurai and me we do not need to store the complete uri. we have refid="109312616" and source="viaf" that should be enough.