Open kasei opened 5 years ago
Maybe xsd:nonNegativeInteger
for integers that cannot be negative (such as tirples, properties).
@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?
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.
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):dc:issued
should bexsd:dateTime
xsd:integer
:hdt:dictionaryblockSize
,hdt:dictionarynumSharedSubjectObject
,hdt:dictionarysizeStrings
,hdt:hdtSize
,hdt:originalSize
,hdt:triplesnumTriples
,void:distinctObjects
,void:distinctSubjects
,void:properties
,void:triples
hdt:dictionarymapping
should be anxsd:integer
, but this might be debatable as it is being used as an enumeration.