Header RDF literals should use appropriate datatypes

[kasei]

The header RDF generated by the rdf2hdt tool asserts many triples with literals that should have datatypes, but don't (instead using simple xsd:string literals):

• The range of dc:issued should be xsd:dateTime
• The range of all of these properties should be xsd:integer: hdt:dictionaryblockSize, hdt:dictionarynumSharedSubjectObject, hdt:dictionarysizeStrings, hdt:hdtSize, hdt:originalSize, hdt:triplesnumTriples, void:distinctObjects, void:distinctSubjects, void:properties, void:triples
• I think the range of hdt:dictionarymapping should be an xsd:integer, but this might be debatable as it is being used as an enumeration.

[wouterbeek]

Maybe xsd:nonNegativeInteger for integers that cannot be negative (such as tirples, properties).

[kasei]

@wouterbeek that would certainly be possible. Personally, I think there's a lot of value (both syntactically and in usability) in trying to use the least-derived xsd type that makes sense. Using xsd:integer would give the obvious syntactic short-form in Turtle, and allows use by simple implementations that lack support for all the xsd derived types.

I don't see a lot of value in perfectly fitting these values with the nonNegativeInteger type because you won't need xsd value-space validation to identify problems in the HDT file; they'll be obvious during the parse. Can you think of use-cases where the xsd validation would be beneficial?

[wouterbeek]

I did not have a specific use case in mind, I was just thinking about how one could use the standards at hand in order to encoding the most semantics. Using xsd:integer i.o. xsd:string would already be a big improvement.