Jump to: navigation, search

Difference between revisions of "SMILA/Documentation/Data Model and Serialization Formats"

(added Binary/BON notation)
m (Examples)
(31 intermediate revisions by 6 users not shown)
Line 2: Line 2:
  
 
* Implementation bundle: <tt>org.eclipse.smila.datamodel</tt>
 
* Implementation bundle: <tt>org.eclipse.smila.datamodel</tt>
* Current Version: 0.8.0
+
* Current Version: 1.0.0
  
 
=== Concepts ===
 
=== Concepts ===
Line 8: Line 8:
 
The data to be processed in SMILA is represented as '''records'''. For example, one record could correspond to one document or to any resource which should be indexed or found in a search. A record consists of '''metadata''' and optional '''attachments'''.  
 
The data to be processed in SMILA is represented as '''records'''. For example, one record could correspond to one document or to any resource which should be indexed or found in a search. A record consists of '''metadata''' and optional '''attachments'''.  
  
[[Image:SMILA-datamodel-0.8.png|800px|SMILA data model version 0.8]]
+
[[Image:SMILA-datamodel-1.0.png|800px|SMILA data model version 1.0]]
  
* Metadata contains typed '''values''' (literals) arranged in '''maps''' (key-anything associations) and '''sequences''' (lists of anything). Values can be strings, long integers, double precision floating point numbers, booleans, dates (year, month, day) or datetimes (date + time of day, down to seconds). Maps and sequences can be nested arbitrarily, map keys are always strings. All metadata of one record is arranged in a single Map.  
+
;Metadata:
* Attachments can contain any binary content ("byte arrays"), possibly of larger size. During indexing they are not kept in memory all the time, but stored in a "binary storage" service and read only when actually needed.
+
Metadata contains typed '''values''' (literals) arranged in '''maps''' (key-anything associations) and '''sequences''' (lists of anything). Values can be strings, long integers, double precision floating point numbers, booleans, dates (year, month, day) or datetimes (date + time of day, down to seconds). Maps and sequences can be nested arbitrarily, map keys are always strings. All metadata of one record is arranged in a single Map.  
 +
;Attachments:
 +
Attachments can contain any binary content ("byte arrays"), possibly of larger size. If the content is kept in-memory or read from a persistence service on-demand depends on the implementation of the interface. Currently the size is limited to 2 GB (maximum size of a Java <tt>byte[]</tt>), but we are planning to extend this in the future.
  
 
A single entry in a record's metadata map is called '''Metadata element'''.
 
A single entry in a record's metadata map is called '''Metadata element'''.
Line 28: Line 30:
 
;RecordID: Every record must contain a single-valued string attribute named "_recordid" which is required to identify the record. It must be unique for all processed records. This must be ensured by whoever created and submitted the record it to the system (this would be crawlers or agents, usually). There is no predefined format of the record ID, hence it can contain any string. So, creating UUIDs or something similar would be entirely sufficient. Also, the producer must place any information needed to access the original data from which the record was produced into explicitly named attributes.
 
;RecordID: Every record must contain a single-valued string attribute named "_recordid" which is required to identify the record. It must be unique for all processed records. This must be ensured by whoever created and submitted the record it to the system (this would be crawlers or agents, usually). There is no predefined format of the record ID, hence it can contain any string. So, creating UUIDs or something similar would be entirely sufficient. Also, the producer must place any information needed to access the original data from which the record was produced into explicitly named attributes.
 
;Source: Every record should also contain a second system attribute named "_source" which contains the ID of the data source (e.g. crawler definition) that produced it. This is used by DeltaIndexing or RecordStorage to perform operations on all records from the same source.
 
;Source: Every record should also contain a second system attribute named "_source" which contains the ID of the data source (e.g. crawler definition) that produced it. This is used by DeltaIndexing or RecordStorage to perform operations on all records from the same source.
 +
 +
==== Date and DateTime formats ====
 +
 +
Internally, date and datetime values are represented as instances of [http://download.oracle.com/javase/6/docs/api/java/util/Date.html <code>java.util.Date</code>], which means that they are stored as the number of milliseconds since January 1, 1970, 00:00:00 GMT. For the string serialization used in XML, JSON or BON (see below) the following rules apply:
 +
 +
* The format of date values is "yyyy-MM-dd" (see [http://download.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html SimpleDateFormat] for the meaning of the format string). The year must have exactly 4 digits, the month and day must have 2 digits.
 +
* The format of datetime values is "yyyy-MM-dd'T'HH:mm:ssZ" or "yyyy-MM-dd'T'HH:mm:ss.SSSZ".
 +
** For the date part the date value rules apply.
 +
** Milliseconds are optional when parsing datetime values from strings, but if given, they must have exactly 3 digits.
 +
** The timezone information must be included and must be either "Z" for GMT/UTC or of the forms "+hhmm" or "-hhmm", e.g. "+0100" for Central European Time (CET, MEZ), or "-0600" for Eastern Standard Time (EST). Of course, using "+0000" or "-0000" for GMT/UTC is fine, too.
 +
** When a datetime value is created by parsing from a string (e.g. by parsing XML, JSON or BON, or using the [http://build.eclipse.org/rt/smila/javadoc/current/org/eclipse/smila/datamodel/DataFactory.html <code>DataFactory.parseFromString</code>] methods, it will be printed in the exactly same way when serialized again when written to XML, JSON or BON (see [http://build.eclipse.org/rt/smila/javadoc/current/org/eclipse/smila/datamodel/ValueFormatHelper.html <code>ValueFormatHelper.getDefaultDateTimeFormat</code>]).
 +
** When a datetime value was created in Java from an instance of <code>java.util.Date</code> immediately, it will be serialized using the default timezone of the creating JVM. The milliseconds will be included, too, even if they are just 000.
  
 
=== XML format ===
 
=== XML format ===
Line 42: Line 56:
 
   <Val key="checked" type="boolean">true</Val>
 
   <Val key="checked" type="boolean">true</Val>
 
   <Val key="created" type="date">2010-12-02</Val>
 
   <Val key="created" type="date">2010-12-02</Val>
   <Val key="lastModified" type="datetime">2010-12-02T16:20:54+01:00</Val>
+
   <Val key="lastModified" type="datetime">2010-12-02T16:20:54.123+0100</Val>
 
   <Seq key="trustee">
 
   <Seq key="trustee">
 
     <Val>group1</Val>
 
     <Val>group1</Val>
Line 76: Line 90:
 
* An object that is part of a map must have an additional ''key'' attribute. Elements of sequences must not have the ''key'' attribute.
 
* An object that is part of a map must have an additional ''key'' attribute. Elements of sequences must not have the ''key'' attribute.
 
* The type of a value is defined by an optional ''type'' attribute, the default is "string".
 
* The type of a value is defined by an optional ''type'' attribute, the default is "string".
* The format of date values is "yyyy-MM-dd" (see [[http://download.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html Javadoc of SimpleDateFormat]] for the meaning of the format string)
+
* See above for description of date and datetime formats.
* The format of datetime values is "yyyy-MM-dd'T'HH:mm:ssZ", i.e. it must include timezone information.
+
 
* The top-level <tt><Map></tt> element of a record is omitted from the XML.
 
* The top-level <tt><Map></tt> element of a record is omitted from the XML.
 
* In XML, the record does not contain the attachment values, but only their names so that a reader knows that there are attachments to be processed.
 
* In XML, the record does not contain the attachment values, but only their names so that a reader knows that there are attachments to be processed.
 +
* Attachments are not supported in the XML format, only the names of attachments are preserved, the attachments themselves (the bytes) are lost
  
 
See package <tt>org.eclipse.smila.datamodel.xml</tt> for serialization helper classes.
 
See package <tt>org.eclipse.smila.datamodel.xml</tt> for serialization helper classes.
 +
 +
{{Bug2|351704|Due to a bug in the JDK's default implementation of XMLStreamReader you should only use xml in version 1.0. When deserializing you either dont specify the XML declaration at all or you must use <source lang='xml'><?xml version="1.0" encoding="utf-8"?></source>}}
  
 
=== JSON format ===
 
=== JSON format ===
Line 96: Line 112:
 
   "checked" : true,
 
   "checked" : true,
 
   "created" : "2010-12-02",
 
   "created" : "2010-12-02",
   "lastModified" : "2010-12-02T16:20:54+01:00",
+
   "lastModified" : "2010-12-02T16:20:54.123+0100",
 
   "trustee" : [ "group1", "group2" ],
 
   "trustee" : [ "group1", "group2" ],
 
   "author" :  
 
   "author" :  
Line 116: Line 132:
 
     }
 
     }
 
   },
 
   },
  "_attachments": ["content", "fulltext"]
+
"_attachments": ["content", "fulltext"]
 
}
 
}
 
</source>
 
</source>
Line 123: Line 139:
 
* Number value types are determined implicitly when parsing JSON:
 
* Number value types are determined implicitly when parsing JSON:
 
** If a number value can be parsed as a long integer, a long value will be created, else it will become a double value.  
 
** If a number value can be parsed as a long integer, a long value will be created, else it will become a double value.  
* Date(time) values are not supported by JSON, so they will be parsed to string values
+
* Date and DateTime are not supported by JSON natively, therefore date and datetime values are printed to JSON as simple strings using the format rules described above. On the other hand, when the JSON parser finds a string value that has a correct date or datetime format, it creates a date or datetime value. The original string is preserved, so when accessing the value "as a string" the client will get the original string. Also, when the object is written to JSON (or BON or XML) again, the original string will be used. So this autodetection should not cause problems even if some string value has the correct format, but is not meant to be a date or datetime.
** So when writing a date(time) value to JSON and read it again, it will be converted to a string value!
+
** You can get back the date(time) value, by calling the appropriate conversion methods (<tt>AnyMap.getDate(), AnyMap.getDateTime(), Value.asDate(), Value.asDateTime()</tt>)
+
 
* Map keys are always strings and must be enclosed in quotes.
 
* Map keys are always strings and must be enclosed in quotes.
* Attachment names can be added as a system attribute "_attachments".
+
* Attachments are not supported in the JSON format, only the names of attachments are preserved, the attachments themselves (the bytes) are lost
  
 
See package <tt>org.eclipse.smila.datamodel.ipc</tt> for serialization helper classes.
 
See package <tt>org.eclipse.smila.datamodel.ipc</tt> for serialization helper classes.
  
 +
=== BON Binary Object Notation Format ===
  
=== Binary format (BON) ===
+
==== Format introduction ====
  
The binary object notation (BON) format is an optimized JSON-like binary representation. SMILA's ipc bundles/classes are designed for easily change between JSON and BON format.
+
The format consists of a sequence of tokens and data with two different types of tokens:
 
+
The BON format consists of a sequence of tokens and data with two different types of tokens:
+
  
 
* Event tokens are single bytes which are describing an event (e.g. OBJECT-START, SEQUENCE-START).
 
* Event tokens are single bytes which are describing an event (e.g. OBJECT-START, SEQUENCE-START).
* Data tokens are the first part of a data entity.
+
* Data tokens are the first part of an entity.
  
Every data entity consists of up to three parts. The first part is a one byte token which describes the following data type and in case of a string type this token is followed by a data length information (second part). The last part is the information itself (except for the boolean type which is stored within the token).
+
Every entity consists of up to three parts. The first part is a one byte token which describes the following data type and in case of a string type this token is followed by a data length information (second part). The last part is the information itself (except for the boolean type which is stored within the token).
  
 
Integer values are stored in a compressed format. The sign and the integer length (number of bytes) are stored in the token byte. Strings are generally stored in UTF-8 format.
 
Integer values are stored in a compressed format. The sign and the integer length (number of bytes) are stored in the token byte. Strings are generally stored in UTF-8 format.
  
====Scalar types====
+
The handling of date and datetime values is exactly as in JSON. See above for detais.
  
* Integer (8 bytes, signed)
+
Attachments are fully supported.
** compressed, bytes are stored in network byte order (big endian)
+
* Double (8 bytes in network byte order IEEE format (java default))
+
* Boolean
+
* String: UTF-8 coded Text Strings, max 2^31-1 bytes
+
  
====List of event tokens====
+
==== Scalar Types ====  
  
{| {{Greytable}}
+
The current release features the following scalar types:
! token
+
 
! description
+
* Integer: [http://en.wikipedia.org/wiki/Integer_(computer_science) signed int64]
! byte
+
** compressed, bytes are stored in [http://en.wikipedia.org/wiki/Network_byte_order#Endianness_in_networking network byte order (big endian)]
|-
+
** −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807
| OBJECT-START
+
* Floating point values:
|
+
** double (8 bytes in network byte order IEEE format (java default))
|25
+
* Bool
|-  
+
* String:
|OBJECT-END
+
** UTF-8 coded Text Strings, max 2^31-1 bytes
|  
+
 
|28
+
==== Integer compressing ====
 +
 
 +
The token bytes 0..15 defines the sign of the number (0-7, positive, 8-15 negative) and the number of the necessary bytes, to store the number. The bytes are stored in network byte order.
 +
 
 +
{|border=1
 +
|+Examples for integer compression
 +
! value !! token !! data
 
|-
 
|-
|SEQUENCE-START
+
|17 || 0 (positiv  1 byte) || 17 (0x 11)
|  
+
|29
+
 
|-
 
|-
|SEQUENCE-END
+
|-17 || 8 (negative 1 bytes) || 17 (0x 11)
|  
+
|30
+
 
|-
 
|-
|MAPPING-START
+
|17985 || 1 (positiv  2 bytes) || 0x 46 41
|  
+
|31
+
 
|-
 
|-
|MAPPING-END
+
|-9.876.543.210 || 12 (negative 5 bytes) || 0x 02 4C B0 16 EA
|  
+
|}
|32
+
 
 +
==== Binary Type ====
 +
 
 +
The Binary type is used for arbitrary binary content in attachments. A single binary is currently limited to a size of max 2^31-1 bytes.
 +
 
 +
==== Token Bytes ====
 +
 
 +
There are two different types of tokens. Here is a complete list of all tokens which are supported by the current release of the format:
 +
 
 +
{|border=1
 +
|+ List of event tokens
 +
! token !! description !! byte
 
|-
 
|-
 +
|OBJECT-START||No version string||25
 +
|-
 +
|OBJECT-START||Followed by version (reserved, not implemented)||26
 +
|-
 +
|OBJECT-END|| ||28
 +
|-
 +
|SEQUENCE-START|| ||29
 +
|-
 +
|SEQUENCE-END|| ||30
 +
|-
 +
|MAPPING-START|| ||31
 +
|-
 +
|MAPPING-END|| ||32
 +
|-
 +
|ATTACHMENTS-START|| ||33
 +
|-
 +
|ATTACHMENTS-END|| ||34
 +
|-
 +
|CUSTOM-TYPE|| ||43
 
|}
 
|}
  
====List of data tokens====
+
{|border=1
 +
|+List of data tokens
 +
! token !! description !! byte
 +
|-
 +
|SCALAR-INT||positiv length 1||0
 +
|-
 +
| ||positiv length 2||1
 +
|-
 +
| ||...||...
 +
|-
 +
| ||positiv length 8||7
 +
|-
 +
| ||negative length 1||8
 +
|-
 +
| ||negative length 2||9
 +
|-
 +
| ||...||...
 +
|-
 +
| ||negative length 8||15
 +
|-
 +
|SCALAR-BOOL||true||16
 +
|-
 +
| ||false||17
 +
|-
 +
|SCALAR-FLOAT||float (32 bit)||18 (reserved, not implemented)
 +
|-
 +
|SCALAR-FLOAT||double (64 bit)||19
 +
|-
 +
|SCALAR-FLOAT||long double (80 bit)||20 (reserved, not implemented)
 +
|-
 +
|SCALAR-STRING||1 length byte||21
 +
|-
 +
| ||2 length byte||22
 +
|-
 +
| ||3 length byte||23
 +
|-
 +
| ||4 length byte||24
 +
|-
 +
|BINARY||length 1||35
 +
|-
 +
| ||length 2||36
 +
|-
 +
| ||length 3||37
 +
|-
 +
| ||length 4||38
 +
|-
 +
| ||length 5||39 (reserved, not implemented)
 +
|-
 +
| ||...||...
 +
|-
 +
| ||length 8||42 (reserved, not implemented)
 +
|}
  
{| {{Greytable}}
+
==== Backward compatible extension concept ====
! token
+
 
! description
+
If we need a BON format extension (= a new token), we pick an unused token number. Token 26 and 27 are reserved to store additional version information, but this is currently not implemented.
! byte
+
 
|-
+
==== Custom Type ====
|SCALAR-INT
+
 
|1-byte positive integer
+
The token CUSTOM-TYPE (43), followed by a type identifier (token SCALAR-STRING/21 + string), marks the following map or sequence as a special custom type. Appropriate parser code can create corresponding user objects.
|0
+
 
|-
+
There is no mapping of this BON format to JSON. The representation in JSON is just the same as if the CUSTOM_TYPE token and the following string would be skipped.
|
+
 
|2-byte positive integer
+
So parsing such a BON without knowing an appropriate custom type is just skipping these extra information and continue.
|1
+
 
 +
==== Examples ====
 +
 
 +
===== Integer =====
 +
 
 +
Sample integer value: '''-36364'''
 +
 
 +
The BON representation:
 +
 
 +
{|border=1
 +
!Value (decimal)!!Info!!Comment
 
|-
 
|-
|  
+
|9||SCALAR-INT||negative int value with 2 bytes length
|...
+
|...
+
 
|-
 
|-
|  
+
|36364||int int value without sign||
|8-byte positive integer
+
|}
|7
+
 
 +
and the hex representation:
 +
<source lang="text">
 +
09 8E 0C
 +
</source>
 +
 
 +
===== String =====
 +
 
 +
Sample text: '''ähnlich'''
 +
 
 +
The BON representation:
 +
 
 +
{|border=1
 +
!Value (decimal)!!Info!!Comment
 
|-
 
|-
|  
+
|21||SCALAR-STRING||string with one byte length info
|1-byte negative integer
+
|8
+
 
|-
 
|-
|  
+
|08||length info||the string follows
|2-byte negative integer
+
|9
+
 
|-
 
|-
|  
+
|ähnlich||the string content||
|...
+
|}
|...
+
 
 +
and the hex representation:
 +
 
 +
<source lang="text">
 +
15 08 c3 a4 68 6e 6c 69 63 68
 +
</source>
 +
 
 +
===== Complex example =====
 +
 
 +
A complex example: This could be some text annotation or highlighting structure. The JSON representation is:
 +
 
 +
<source lang="javascript">
 +
{
 +
  "title": [
 +
    ["STEM","the",0,2],
 +
    ["STEM","title",4,8]
 +
  ]
 +
}
 +
</source>
 +
 
 +
{|border=1
 +
!Value (decimal)!!Info!!Comment
 
|-
 
|-
|  
+
|25||OBJECT-START|| "---" (here: without Type:version)
|8-byte negative integer
+
|15
+
 
|-
 
|-
|SCALAR-BOOL
+
|31||MAPPING-START||
|true
+
|16
+
 
|-
 
|-
|  
+
|21||SCALAR-STRING||string with one byte length info
|false
+
|17
+
 
|-
 
|-
|SCALAR-FLOAT
+
|5|| || length info of the string
|float (32 bit)
+
|18 (reserved, not implemented)
+
 
|-
 
|-
|SCALAR-FLOAT
+
|title|| || the string content
|double (64 bit)
+
|19
+
 
|-
 
|-
|SCALAR-FLOAT
+
|29||SEQUENCE-START||start of the sequence "STEM,the,0,2"
|long double (80 bit)
+
|20 (reserved, not implemented)
+
 
|-
 
|-
|SCALAR-STRING
+
|21||SCALAR-STRING||string with one byte length info
|1-byte string length
+
|21
+
 
|-
 
|-
|  
+
|4|| || length info for "STEM"
|2-byte string length
+
|22
+
 
|-
 
|-
|  
+
|STEM|| ||the string content
|3-byte string length
+
|23
+
 
|-
 
|-
|  
+
|21||SCALAR-STRING||string with one byte length info
|4-byte string length
+
|24
+
 
|-
 
|-
 +
|3|| || length info for "the"
 +
|-
 +
|the|| || the string content
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|0|| || the INT value
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|2|| || the INT value
 +
|-
 +
|30||SEQUENCE-END||end of the sequence "STEM,the,0,2"
 +
|-
 +
|29||SEQUENCE-START||start of the sequence "STEM,title,4,8"
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|4|| || length info for "STEM"
 +
|-
 +
|STEM|| || the string content
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|5|| || length info for "title"
 +
|-
 +
|title|| || the string content
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|4|| || the INT value
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|8|| || the INT value
 +
|-
 +
|30||SEQUENCE-END||end of the sequence "STEM,title,4,8"
 +
|-
 +
|32||MAPPING-END||
 +
|-
 +
|28||OBJECT-END||
 
|}
 
|}
  
See package <tt>org.eclipse.smila.datamodel.ipc</tt> for serialization helper classes.
 
  
 +
===== Complex example with Custom Type =====
 +
 +
If there is a custom type "text":
 +
 +
{|border=1
 +
!Value (decimal)!!Info!!Comment
 +
|-
 +
|25||OBJECT-START|| "---" (here: without Type:version)
 +
|-
 +
|31||MAPPING-START||
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|5|| || length info of the string
 +
|-
 +
|title|| || the string content
 +
|-
 +
|43||CUSTOM-TYPE|| a custom type follows
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|4|| || length info for "text"
 +
|-
 +
|text|| ||the string content
 +
|-
 +
|29||SEQUENCE-START||start of the sequence "STEM,the,0,2"
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|4|| || length info for "STEM"
 +
|-
 +
|STEM|| ||the string content
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|3|| || length info for "the"
 +
|-
 +
|the|| || the string content
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|0|| || the INT value
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|2|| || the INT value
 +
|-
 +
|30||SEQUENCE-END||end of the sequence "STEM,the,0,2"
 +
|-
 +
|29||SEQUENCE-START||start of the sequence "STEM,title,4,8"
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|4|| || length info for "STEM"
 +
|-
 +
|STEM|| || the string content
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|5|| || length info for "title"
 +
|-
 +
|title|| || the string content
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|4|| || the INT value
 +
|-
 +
|0||SCALAR-INT (positive)||with one byte length
 +
|-
 +
|8|| || the INT value
 +
|-
 +
|30||SEQUENCE-END||end of the sequence "STEM,title,4,8"
 +
|-
 +
|32||MAPPING-END||
 +
|-
 +
|28||OBJECT-END||
 +
|}
 +
 +
 +
===== Complex example with attachments =====
 +
 +
Another example with attachments: This could be some input record generated by a crawler (e.g. a mail crawler). The JSON representation is:
 +
 +
<source lang="javascript">
 +
{
 +
  "subject": "a test mail",
 +
  "_attachments" : ["pdfFile", "zipFile"]
 +
}
 +
</source>
 +
 +
Note that "_attachments" is not a regular metadata field but contains the name of the attachments. Also note that the JSON representation does not contain the attachments themselves. This is only for documentation purpose.
 +
 +
 +
{|border=1
 +
!Value (decimal)!!Info!!Comment
 +
|-
 +
|25||OBJECT-START|| "---" (here: without Type:version)
 +
|-
 +
|31||MAPPING-START||
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|7|| || length info for the string
 +
|-
 +
|subject|| || the string content
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|11|| || length info for "a test mail"
 +
|-
 +
|a test mail|| || the string content
 +
|-
 +
|32||MAPPING-END||
 +
|-
 +
|33||ATTACHMENTS-START||
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|7|| || length info the string
 +
|-
 +
|pdfFile|| || the string content
 +
|-
 +
|35||BINARY|| binary with 1 byte length info
 +
|-
 +
|12345|| || length info for the binary content
 +
|-
 +
| 03x0815 .... || || the binary content
 +
|-
 +
|21||SCALAR-STRING||string with one byte length info
 +
|-
 +
|7|| || length info for the string
 +
|-
 +
|zipFile|| || the string content
 +
|-
 +
|35||BINARY|| binary with 1 byte length info
 +
|-
 +
|98765|| || length info for the binary content
 +
|-
 +
| 08x4711 .... || || the binary content
 +
|-
 +
|34||ATTACHMENTS-END||
 +
|-
 +
|28||OBJECT-END||
 +
|}
  
 
=== Record Filters ===
 
=== Record Filters ===

Revision as of 08:46, 25 February 2013

SMILA Data Model

  • Implementation bundle: org.eclipse.smila.datamodel
  • Current Version: 1.0.0

Concepts

The data to be processed in SMILA is represented as records. For example, one record could correspond to one document or to any resource which should be indexed or found in a search. A record consists of metadata and optional attachments.

SMILA data model version 1.0

Metadata

Metadata contains typed values (literals) arranged in maps (key-anything associations) and sequences (lists of anything). Values can be strings, long integers, double precision floating point numbers, booleans, dates (year, month, day) or datetimes (date + time of day, down to seconds). Maps and sequences can be nested arbitrarily, map keys are always strings. All metadata of one record is arranged in a single Map.

Attachments

Attachments can contain any binary content ("byte arrays"), possibly of larger size. If the content is kept in-memory or read from a persistence service on-demand depends on the implementation of the interface. Currently the size is limited to 2 GB (maximum size of a Java byte[]), but we are planning to extend this in the future.

A single entry in a record's metadata map is called Metadata element. According to the use case, metadata elements can be semantically interpreted as:

Attributes
Usually, attributes are used when referring to the metadata of an object which is to be processed from a given data source or which is retrieved as the result of a search request. For example, typical attributes characterizing a web page to be indexed are its URL, the size in bytes, the MIME type, the title, and the plain-text content. These attributes are defined by the application domain.
Parameters
Attributes may not be adequate or sufficient for all record types. For example, in search processing, a record represents not a single object from some data source but rather a search request object. In such a case, the record's metadata does not contain attributes from the application domain on top-level but rather request parameters that configure and influence the request execution. These parameters are defined by the pipelets which are used in the workflow that was triggered by the search request. Also, their names do not start with underscores. However, a request or result record may contain application-specific attributes on deeper nested levels. Find an example, hopefully illustrating the difference between attributes and parameters, in Search API.
Annotations
An annotation can be used to add a data structure to the record which was generated as the result of some processing step. E.g., a named-entity-recognition pipelet could add an annotation describing at which character position some entity was found, meaning that the record was annotated with this additional information. If annotations appear in the same maps as attributes, their names should be chosen in such a way that they will not conflict with attribute names from the application, e.g. by prefixing them with an underscore "_".
System attributes
These attributes are needed by SMILA in order to coordinate the processing of a record (see below). Their names start with an underscore "_", so that they will not conflict with names from the application domain.

System attributes

RecordID
Every record must contain a single-valued string attribute named "_recordid" which is required to identify the record. It must be unique for all processed records. This must be ensured by whoever created and submitted the record it to the system (this would be crawlers or agents, usually). There is no predefined format of the record ID, hence it can contain any string. So, creating UUIDs or something similar would be entirely sufficient. Also, the producer must place any information needed to access the original data from which the record was produced into explicitly named attributes.
Source
Every record should also contain a second system attribute named "_source" which contains the ID of the data source (e.g. crawler definition) that produced it. This is used by DeltaIndexing or RecordStorage to perform operations on all records from the same source.

Date and DateTime formats

Internally, date and datetime values are represented as instances of java.util.Date, which means that they are stored as the number of milliseconds since January 1, 1970, 00:00:00 GMT. For the string serialization used in XML, JSON or BON (see below) the following rules apply:

  • The format of date values is "yyyy-MM-dd" (see SimpleDateFormat for the meaning of the format string). The year must have exactly 4 digits, the month and day must have 2 digits.
  • The format of datetime values is "yyyy-MM-dd'T'HH:mm:ssZ" or "yyyy-MM-dd'T'HH:mm:ss.SSSZ".
    • For the date part the date value rules apply.
    • Milliseconds are optional when parsing datetime values from strings, but if given, they must have exactly 3 digits.
    • The timezone information must be included and must be either "Z" for GMT/UTC or of the forms "+hhmm" or "-hhmm", e.g. "+0100" for Central European Time (CET, MEZ), or "-0600" for Eastern Standard Time (EST). Of course, using "+0000" or "-0000" for GMT/UTC is fine, too.
    • When a datetime value is created by parsing from a string (e.g. by parsing XML, JSON or BON, or using the DataFactory.parseFromString methods, it will be printed in the exactly same way when serialized again when written to XML, JSON or BON (see ValueFormatHelper.getDefaultDateTimeFormat).
    • When a datetime value was created in Java from an instance of java.util.Date immediately, it will be serialized using the default timezone of the creating JVM. The milliseconds will be included, too, even if they are just 000.

XML format

The XML format of a record is designed to be quite compact:

<Record xmlns="http://www.eclipse.org/smila/record" version="2.0">
  <Val key="_recordid">web:http://example.org/something</Val>
  <Val key="_source">web</Val>
  <Val key="url">http://example.org/something</Val>
  <Val key="filesize" type="long">1234</Val>
  <Val key="sizeInKb" type="double">1.2</Val>
  <Val key="checked" type="boolean">true</Val>
  <Val key="created" type="date">2010-12-02</Val>
  <Val key="lastModified" type="datetime">2010-12-02T16:20:54.123+0100</Val>
  <Seq key="trustee">
    <Val>group1</Val>
    <Val>group2</Val>
  </Seq>
  <Seq key="author">
    <Map>
      <Val key="firstname">John</Val>
      <Val key="lastname">Doe</Val>
    </Map>
    <Map>
      <Val key="firstname">Lisa</Val>
      <Val key="lastname">Müller</Val>
    </Map>
  </Seq>  
  <Map key="contact">
    <Val key="email">Homer.Simpson@powerplant.com</Val>      
    <Map key="address">
      <Val key="street">742 Evergreen Terrace</Val>
      <Val key="city">Springfield</Val>
    </Map>
  </Map>
  <Seq key="emptylist" />
  <Map key="emptymap" />
 
  <Attachment>content</Attachment>
  <Attachment>fulltext</Attachment>
</Record>

Notes:

  • The Any objects are represented by <Val>, <Map>, and <Seq> elements.
  • An object that is part of a map must have an additional key attribute. Elements of sequences must not have the key attribute.
  • The type of a value is defined by an optional type attribute, the default is "string".
  • See above for description of date and datetime formats.
  • The top-level <Map> element of a record is omitted from the XML.
  • In XML, the record does not contain the attachment values, but only their names so that a reader knows that there are attachments to be processed.
  • Attachments are not supported in the XML format, only the names of attachments are preserved, the attachments themselves (the bytes) are lost

See package org.eclipse.smila.datamodel.xml for serialization helper classes.

Bug.png
351704
Due to a bug in the JDK's default implementation of XMLStreamReader you should only use xml in version 1.0. When deserializing you either dont specify the XML declaration at all or you must use
<?xml version="1.0" encoding="utf-8"?>


JSON format

The JSON format of a record looks like this:

{
  "_recordid" : "web:http://example.org/something",
  "_source" : "web",
  "url" : "web:http://example.org/something",
  "filesize" : 1234,
  "sizeInKb" : 1.2,
  "checked" : true,
  "created" : "2010-12-02",
  "lastModified" : "2010-12-02T16:20:54.123+0100",
  "trustee" : [ "group1", "group2" ],
  "author" : 
  [ {
      "firstname" : "John",
      "lastname" : "Doe"
    },
    {
      "firstname" : "Lisa",
      "lastname" : "Müller"
    } ],
  "contact" : 
  {
    "email" : "Homer.Simpson@powerplant.com",
    "address" : 
    {
      "street" : "742 Evergreen Terrace",
      "city" : "Springfield"
    }
  },
 "_attachments": ["content", "fulltext"]
}

Notes:

  • Number value types are determined implicitly when parsing JSON:
    • If a number value can be parsed as a long integer, a long value will be created, else it will become a double value.
  • Date and DateTime are not supported by JSON natively, therefore date and datetime values are printed to JSON as simple strings using the format rules described above. On the other hand, when the JSON parser finds a string value that has a correct date or datetime format, it creates a date or datetime value. The original string is preserved, so when accessing the value "as a string" the client will get the original string. Also, when the object is written to JSON (or BON or XML) again, the original string will be used. So this autodetection should not cause problems even if some string value has the correct format, but is not meant to be a date or datetime.
  • Map keys are always strings and must be enclosed in quotes.
  • Attachments are not supported in the JSON format, only the names of attachments are preserved, the attachments themselves (the bytes) are lost

See package org.eclipse.smila.datamodel.ipc for serialization helper classes.

BON Binary Object Notation Format

Format introduction

The format consists of a sequence of tokens and data with two different types of tokens:

  • Event tokens are single bytes which are describing an event (e.g. OBJECT-START, SEQUENCE-START).
  • Data tokens are the first part of an entity.

Every entity consists of up to three parts. The first part is a one byte token which describes the following data type and in case of a string type this token is followed by a data length information (second part). The last part is the information itself (except for the boolean type which is stored within the token).

Integer values are stored in a compressed format. The sign and the integer length (number of bytes) are stored in the token byte. Strings are generally stored in UTF-8 format.

The handling of date and datetime values is exactly as in JSON. See above for detais.

Attachments are fully supported.

Scalar Types

The current release features the following scalar types:

  • Integer: signed int64
  • Floating point values:
    • double (8 bytes in network byte order IEEE format (java default))
  • Bool
  • String:
    • UTF-8 coded Text Strings, max 2^31-1 bytes

Integer compressing

The token bytes 0..15 defines the sign of the number (0-7, positive, 8-15 negative) and the number of the necessary bytes, to store the number. The bytes are stored in network byte order.

Examples for integer compression
value token data
17 0 (positiv 1 byte) 17 (0x 11)
17985 1 (positiv 2 bytes) 0x 46 41

Binary Type

The Binary type is used for arbitrary binary content in attachments. A single binary is currently limited to a size of max 2^31-1 bytes.

Token Bytes

There are two different types of tokens. Here is a complete list of all tokens which are supported by the current release of the format:

List of event tokens
token description byte
OBJECT-START No version string 25
OBJECT-START Followed by version (reserved, not implemented) 26
OBJECT-END 28
SEQUENCE-START 29
SEQUENCE-END 30
MAPPING-START 31
MAPPING-END 32
ATTACHMENTS-START 33
ATTACHMENTS-END 34
CUSTOM-TYPE 43
List of data tokens
token description byte
SCALAR-INT positiv length 1 0
positiv length 2 1
... ...
positiv length 8 7
negative length 1 8
negative length 2 9
... ...
negative length 8 15
SCALAR-BOOL true 16
false 17
SCALAR-FLOAT float (32 bit) 18 (reserved, not implemented)
SCALAR-FLOAT double (64 bit) 19
SCALAR-FLOAT long double (80 bit) 20 (reserved, not implemented)
SCALAR-STRING 1 length byte 21
2 length byte 22
3 length byte 23
4 length byte 24
BINARY length 1 35
length 2 36
length 3 37
length 4 38
length 5 39 (reserved, not implemented)
... ...
length 8 42 (reserved, not implemented)

Backward compatible extension concept

If we need a BON format extension (= a new token), we pick an unused token number. Token 26 and 27 are reserved to store additional version information, but this is currently not implemented.

Custom Type

The token CUSTOM-TYPE (43), followed by a type identifier (token SCALAR-STRING/21 + string), marks the following map or sequence as a special custom type. Appropriate parser code can create corresponding user objects.

There is no mapping of this BON format to JSON. The representation in JSON is just the same as if the CUSTOM_TYPE token and the following string would be skipped.

So parsing such a BON without knowing an appropriate custom type is just skipping these extra information and continue.

Examples

Integer

Sample integer value: -36364

The BON representation:

Value (decimal) Info Comment
9 SCALAR-INT negative int value with 2 bytes length
36364 int int value without sign

and the hex representation:

09 8E 0C
String

Sample text: ähnlich

The BON representation:

Value (decimal) Info Comment
21 SCALAR-STRING string with one byte length info
08 length info the string follows
ähnlich the string content

and the hex representation:

 
15 08 c3 a4 68 6e 6c 69 63 68
Complex example

A complex example: This could be some text annotation or highlighting structure. The JSON representation is:

{
  "title": [
    ["STEM","the",0,2],
    ["STEM","title",4,8]
  ]
}
Value (decimal) Info Comment
25 OBJECT-START "---" (here: without Type:version)
31 MAPPING-START
21 SCALAR-STRING string with one byte length info
5 length info of the string
title the string content
29 SEQUENCE-START start of the sequence "STEM,the,0,2"
21 SCALAR-STRING string with one byte length info
4 length info for "STEM"
STEM the string content
21 SCALAR-STRING string with one byte length info
3 length info for "the"
the the string content
0 SCALAR-INT (positive) with one byte length
0 the INT value
0 SCALAR-INT (positive) with one byte length
2 the INT value
30 SEQUENCE-END end of the sequence "STEM,the,0,2"
29 SEQUENCE-START start of the sequence "STEM,title,4,8"
21 SCALAR-STRING string with one byte length info
4 length info for "STEM"
STEM the string content
21 SCALAR-STRING string with one byte length info
5 length info for "title"
title the string content
0 SCALAR-INT (positive) with one byte length
4 the INT value
0 SCALAR-INT (positive) with one byte length
8 the INT value
30 SEQUENCE-END end of the sequence "STEM,title,4,8"
32 MAPPING-END
28 OBJECT-END


Complex example with Custom Type

If there is a custom type "text":

Value (decimal) Info Comment
25 OBJECT-START "---" (here: without Type:version)
31 MAPPING-START
21 SCALAR-STRING string with one byte length info
5 length info of the string
title the string content
43 CUSTOM-TYPE a custom type follows
21 SCALAR-STRING string with one byte length info
4 length info for "text"
text the string content
29 SEQUENCE-START start of the sequence "STEM,the,0,2"
21 SCALAR-STRING string with one byte length info
4 length info for "STEM"
STEM the string content
21 SCALAR-STRING string with one byte length info
3 length info for "the"
the the string content
0 SCALAR-INT (positive) with one byte length
0 the INT value
0 SCALAR-INT (positive) with one byte length
2 the INT value
30 SEQUENCE-END end of the sequence "STEM,the,0,2"
29 SEQUENCE-START start of the sequence "STEM,title,4,8"
21 SCALAR-STRING string with one byte length info
4 length info for "STEM"
STEM the string content
21 SCALAR-STRING string with one byte length info
5 length info for "title"
title the string content
0 SCALAR-INT (positive) with one byte length
4 the INT value
0 SCALAR-INT (positive) with one byte length
8 the INT value
30 SEQUENCE-END end of the sequence "STEM,title,4,8"
32 MAPPING-END
28 OBJECT-END


Complex example with attachments

Another example with attachments: This could be some input record generated by a crawler (e.g. a mail crawler). The JSON representation is:

{
  "subject": "a test mail",
  "_attachments" : ["pdfFile", "zipFile"]
}

Note that "_attachments" is not a regular metadata field but contains the name of the attachments. Also note that the JSON representation does not contain the attachments themselves. This is only for documentation purpose.


Value (decimal) Info Comment
25 OBJECT-START "---" (here: without Type:version)
31 MAPPING-START
21 SCALAR-STRING string with one byte length info
7 length info for the string
subject the string content
21 SCALAR-STRING string with one byte length info
11 length info for "a test mail"
a test mail the string content
32 MAPPING-END
33 ATTACHMENTS-START
21 SCALAR-STRING string with one byte length info
7 length info the string
pdfFile the string content
35 BINARY binary with 1 byte length info
12345 length info for the binary content
03x0815 .... the binary content
21 SCALAR-STRING string with one byte length info
7 length info for the string
zipFile the string content
35 BINARY binary with 1 byte length info
98765 length info for the binary content
08x4711 .... the binary content
34 ATTACHMENTS-END
28 OBJECT-END

Record Filters

Record filters produce reduced copies of a record: A record filter has a name and contains a list of metadata element names. When applied to a record, it produces a copy of the record that contains only the elements of the list.

Record filters are described in a simple XML format:

<RecordFilters>
  <Filter name="filter0" />
  <Filter name="filter1">
    <Element name="attribute" />
  </Filter>
  <Filter name="filter3">
    <Element name="attribute1" />
    <Element name="attribute2" />
    <Element name="attribute3" />
  </Filter>
  <Filter name="filter-all">
    <Element name="*"  />
  </Filter>
</RecordFilters>

Notes:

  • A filter always copies the system elements "_recordid" and "_source". Therefore, the apparently empty "filter0" in this definition produces records that still contain these system elements.
  • A filter may contain arbitrary numbers of element names. It's fine if an element does not appear in the record to copy, it's just ignored.
  • A filter always removes attachments: The "filter-all" in this definition produces a copy of the record with all metadata elements, but not attachments.

Filters are usually applied by asking the blackboard for a filtered copy of the record's metadata. See Blackboard service API for details. To work with filters directly, see package org.eclipse.smila.datamodel.filter for utility classes.