Talk:JSON Export of Wiki Keys (Key Start, Switch, Image Switch etc.)

From Biowikifarm Metawiki
Jump to: navigation, search

Add language to title, caption etc.

Language specific:

  • branches.data. …
    … .title.de, … .title.en
  • informations.data. …
    … .title.de
    … .content.de
  • images.data. …
    … .alt_text.de
    … .description.de

--Andreas Plank (talk) 10:30, 15 April 2013 (CEST)

Presets

Definition and changes of JSON data exchange.

Presets of netzweber GmbH

 1 {
 2   "branches":{
 3     "count":"2",
 4     "data":[
 5       {
 6         "id":"",
 7         "leftId":"",
 8         "rightId":"",
 9         "level":"",
10         "title":{
11           "de":"Titel des Astes",
12           "en":"Branch title"
13         },
14         "informationIds":[1,2,3],
15         "createdAt":"2013-03-13 12:58:14",
16         "createdBy":"username",
17         "updatedAt":"2013-03-13 12:58:14",
18         "updatedBy":"username"
19       },
20       {
21         "id":"",
22         "leftId":"",
23         "rightId":"",
24         "level":"",
25         "title":{"de":"Titel des Astes","en":"Branch title"},
26         "informationIds":[1,2,3],
27         "createdAt":"2013-03-13 12:58:14",
28         "createdBy":"username",
29         "updatedAt":"2013-03-13 12:58:14",
30         "updatedBy":"username"
31       }
32     ]
33   },
34   "informations":{
35     "count":"2",
36     "data":[
37       {
38         "id":"",
39         "title":{"de":"Titel der Information","en":"Title of the information"},
40         "content":{"de":"Inhalt","en":"Content"},
41         "createdAt":"2013-03-13 12:58:14",
42         "createdBy":"username",
43         "updatedAt":"2013-03-13 12:58:14",
44         "updatedBy":"username",
45         "imageIds":[10,20,30]
46       },
47       {
48         "id":"",
49         "title":{"de":"Titel der Information","en":"Title of the information"},
50         "content":{"de":"Inhalt","en":"Content"},
51         "createdAt":"2013-03-13 12:58:14",
52         "createdBy":"username",
53         "updatedAt":"2013-03-13 12:58:14",
54         "updatedBy":"username",
55         "imageIds":[10,20,30]
56       }
57     ]
58   },
59   "images":{
60     "count":"2",
61     "data":[
62       {
63         "id":"",
64         "title":{"de":"Bildtitel","en":"Image title"},
65         "alt_text":{"de":"Alt-Text DE","en":"Alt-Text EN"},
66         "description":{"de":"Beschreibung","en":"Description"},
67         "url":""
68       },
69       {
70         "id":"",
71         "title":{"de":"Bildtitel","en":"Image title"},
72         "alt_text":{"de":"Alt-Text DE","en":"Alt-Text EN"},
73         "description":{"de":"Beschreibung","en":"Description"},
74         "url":""
75       }
76     ]
77   }
78 }

Changes:

line number old new notes
15, 27 branches.data.createdAt branches.data.created use Dublincore created
41, 51 informations.data.createdAt informations.data.created use Dublincore created

result.text

result.text is composed of
result_text ?
  ├ y result_text
  └ n scientific_name ?
      ├ y common_names ?
      │   ├ y common_names + scientific_name
      │   └ n scientific_name
      └ n result ?
          ├ y result
          └ n common_names ?
              ├ y common_names
              └ n mobilekey2_keyresult_help_todo
key_recursion_depth == max_key_recursion_depth (=50) ?
 ├ y result_text + mobilekey2_error_stop_childkeys
 └ n result_text

--Andreas Plank (talk) 11:28, 7 June 2013 (CEST)

numeric record id

A (constant) numeric record id is needed by netzweber.de. Presently there are the following nid calculations (can/might be changed)

  • content[].decision[].nid
  • content[].decision[].alternative[].nid

Requirements of this ID:

  • constant (in time, i.e. after changes at later import it should be the same ID)
  • no zero-fill

This id is an integer and can be composed of the unique Wiki article-ID and several indices:

XXXXXXXXXXX
│   │ │  │ 
│   │ │  (two zerofilled digits: 00-99) index of alternative
│   │ (three zerofilled digits: 000-999) index of decision
│   (two zerofilled digits: 00-99) index of fragment-id on a wiki page
article-ID (variable digits, but unique article id)

NOTE: this id keeps constant only if the sequence order of decisions or alternatives keep unchanged. --Andreas Plank (talk) 14:27, 11 June 2013 (CEST)

Cross references

Cases:

  • local reference links: href="#local-id" → prepend content.id: href="wiki_page_name_wikipage#local-id"
  • local ordinary links: href="#local-id" → prepend content.id: href="wiki_page_name_wikipage#local-id"
  • local {{Lead Link}} → not yet done
  • glossary / clue tips → href="page-URL" → replace page-URL by content.id: href="wiki_page_name_glossary#optional-local-id"

--Andreas Plank (talk) 17:30, 14 June 2013 (CEST)

Caching media to local file names

For the purpose of being offline but using all media it's necessary to cache them. A separate media collection can speed up the caching process. In addition statements, remarks or the content.type:"html" can contain inline images too, they also need to be cached as custom sized images. The proposal is to add a file id (local_file_id) to the media object of an alternative that points to the new media collection and this is also the local file name.

DESIRABLE: APP can decide whether to download only small, or also large, or even max.

The media file name to the local storage is recommended to the local file id, in three folders: /small/, /large/ and /max/

Example

localstore/small/420px-123.jpg
localstore/large/1000px-123.jpg 
localstore/max/123.jpg


OldNew
content
└ decision
  └ alternative
    └ media:
      ├ type: "primary" | "large_primary" | "collapsed"
      ├ caption:         (html)
      ├ label:           (plain text) figure label
      ├ url_420px:       URL to 420px sized media
      ├ url_1000px:      URL to 1000px sized media
      ├ custom_height:   a specific height is used
      ├ custom_width:    a specific width is used
      ├ custom_url:      URL to the specified sized media
      ├ url_maxres:      URL of media with highest resolution
      ├ mimetype:        mime type of this media file
      ├ error:           any error that occurs during export that is worth reporting
      └ meta_url:        URL of meta data page
      
content
└ decision
  └ alternative
    └ media: [{"":"", "":""}, {"":"", "":""}]
      ├ type: "primary" | "large_primary" | "collapsed"
      ├ caption:
      ├ label:
      ├ url_420px:     → moves to media[].small: {"":""}
      ├ url_1000px:    → moves to media[].large: {"":""}
      ├ custom_height: → removed
      ├ custom_width:  → removed
      ├ custom_url:    → removed
      ├ url_maxres:    → moves to media[].max:   {"":""}
      ├ mimetype:      → moves to media[].small: {"":""}, media[].large: {"":""} and media[].max: {"":""}
      ├ error:         → moves to media[].error
      ├ meta_url:      → moves to media[].small: {"":""}, media[].large: {"":""} and media[].max: {"":""}
      └ local_file_id: (=local file name)

Add a new media collection in the JSON root with local_file_id as key. This collection contains then also inline images of statements and content.type:"html"

media: [{"":"", "":""}, {"":"", "":""}]
├ local_file_id:  (=id of local file name)
├ meta_url:       URL of meta data page (page context, containing the metadata like author, license, etc.)
├ error:
├ small: {"":"", "":""} up to … 420px
· ├ url:          URL for max 420px sized media (smaller if only smaller available)
· ├ height:       height of this variant
· ├ width:        width of this variant
· └ mimetype:     mime type of this of this variant
├ large: {"":"", "":""} up to 421px … 1000px
· ├ url:          URL for max 1000px sized media (missing if largest is 420, smaller than 1000 if only 421-999px available)
· ├ height:       height of this variant
· ├ width:        width of this variant
· └ mimetype:     mime type of this of this variant 
└ max:  {"":"", "":""}
  ├ url:          URL of media with highest possible resolution, missing if largest is <1001px 
  ├ height:       height of this variant
  ├ width:        width of this variant
  └ mimetype:     mime type of this of this variant 

What is more clear: localref_id or local_file_id? --Andreas Plank (talk) 10:56, 24 July 2013 (CEST)

localref_id → local_file_id --Andreas Plank (talk) 13:55, 24 July 2013 (CEST)

Not sure if custom_width and custom_heigth belong to the root media collection, because local_file_id (=file name) will be based on the sized file name that is originally used. --Andreas Plank (talk) 13:17, 24 July 2013 (CEST)

custom_width and custom_heigth must move to the root media object --Gregor Hagedorn 23:27, 24 July 2013 (CEST)
removed anyway due to misunderstanding. Let the app choose what size fits best. --Andreas Plank (talk) 15:37, 25 July 2013 (CEST)

Inline images

Besides the explicit image references in json, it is possible that html-inline images exist. Inline images can occur in html text (parsed page context) or in the decision tree alternatives, e.g. in statements or remarks or description. It is to clarify …

1. How to communicate a desired media size to the app?

2. Where to save and localize those images?

It is expected that the app will localize the files to local storage. The path to this storage can be freely chosen.

add 2. Where to save and localize those images?

These will use a place-holder path of "$LOCAL_MEDIA_PATH" which must be replaced prior to displaying html content blocks or html inside a decision statement or caption.

PROBLEM: inline image 1 is mini-pupil of frog, 16 px. So if the image tag inside html would be:
Bla <img src="$LOCAL_MEDIA_PATH/16px-123.jpg" height="16" width="16"> bla bla
all is well, the app might choose to make /small/ part of the path expansion

But inline image 2 is full size image of plant in the portrait.
Bla <img src="$LOCAL_MEDIA_PATH/1000px-123.jpg" height="900" width="1000"> bla bla
Can the app again choose /small/? Probably it has to, if only small was downloaded. However, also 1000px may have been downloaded.

**** DOES THE APP HAVE TO PARSE INTO THE IMG TAGS TO FIGURE OUT WHICH px-size is desired? **** --Gregor Hagedorn 14:27, 25 July 2013 (CEST)

What about using the data-… attribute without prefix of $LOCAL_MEDIA_PATH to indicate the desired size and therefore the recommended local (relative) path?
Bla <img data-recommended-filesize="large" src="1000px-123.jpg" height="900" width="1000"> bla bla
Bla <img data-recommended-filesize="small" src="16px-123.jpg" height="16" width="16"> bla bla
--Andreas Plank (talk) 15:37, 25 July 2013 (CEST)

add 2. How to communicate a desired media size to the app?

----------------------------   ----------------------------
         available                   data provided for        
----------------------------   ----------------------------
          421px…    1001px…              421px…    1001px… 
 …420px   …1000px   …max.px     …420px   …1000px   …max.px
    av       av        av          y        y         y       the app decides
    av       av        NA          y        y         no      the app decides
    av       NA        NA          y        no        no      the app decides
    NA       NA        NA          no       no        no      an error message should be provided
----------------------------   ----------------------------
 inline size originally          
 used but files are all                              
 available                          data provided for      
----------------------------   ----------------------------
   used      -         -           *       *?        *?
    -      used        -          *?        *        *?
    -        -        used         *        *         *

Should we provide the data for "*?"-question marks? --Andreas Plank (talk) 15:37, 25 July 2013 (CEST)

Step to another content block (result.next_id, result.ref or result.ref_id)

Presently there are

  • result.next_id → pointing always to content.decision.id
  • result.ref defined as (plain text; result.ref OR result.url not both) wiki_page_name#optional-fragment-id

Because result.next_id points only to content.decision.id and when there is no further decision but a content.type:"html", at this point nothing points to the content.id (wiki_page_name_wikipage). We need a pointer to content.id in case when there is no further decision but a content.type:"html"

  • Why do we need a wiki_page_name#optional-fragment-id in ref when it is not used (maybe its definition of the value should be adapted)? Or what was was the intention of result.ref?
  • Shall it be implemented by result.ref with a value like wiki_page_name_wikipage#optional-fragment-id?
  • Shall we replace result.ref by result.ref_id with a value like wiki_page_name_wikipage#optional-fragment-id?

--Andreas Plank (talk) 09:28, 6 August 2013 (CEST)

Cases for stepping through decisions Used linkage parameter
decision within a content block result.next_id
+ result.next_code ?? OR WHAT IS THE RIGHT PROPERTY --WikiSysop 11:42, 6 August 2013
Of course there is a result.next_code but my concern is on the linkage parameter, that points to the next thing, not the display text or next_cote etc. --Andreas Plank (talk) 13:30, 6 August 2013 (CEST)
decision in another content block (Wikipage with a key) result.next_id + result.ref
only a Wiki-page, no key not clear: something must point to wiki_page_name_wikipage#optional-fragment-id (either result.ref or a result.ref_id)
I propose to use + result.ref for this. HOWEVER, we could replace next_id with next_decision and result.ref with result.next_content. --WikiSysop 11:42, 6 August 2013
Sounds reasonable and looks clear:
replace result.next_id → result.next_decision
and result.ref → result.next_content --Andreas Plank (talk) 13:30, 6 August 2013 (CEST)

We also introduce a result.html_fragment_id --Andreas Plank (talk) 12:45, 7 August 2013 (CEST)

only external link result.url + result.text
?? IS result.text OPTIONAL? --WikiSysop 11:42, 6 August 2013
Of course there is a result.text but my concern is on the linkage parameter, that points to the next thing, not the display text or next_cote etc. --Andreas Plank (talk) 13:30, 6 August 2013 (CEST)
only result.text, no link result.text only (no result.ref, result.url is filled)