Meeting minutes
DICOM
erich: Favor option 5. Prob most favorable to DICOM community too. And suggest a mapping to option 9.
detlef: Why would we need option 5?
erich: It keeps the datatype. But 9 is nice and clean, easy to look at.
erich: I would use 9 internally, because I have 20B triples, and it saves a lot of triples by dropping the datatypes.
eric: I like 5
gaurav: this looks good. Like the null flavor. Favor 5.
jim: Does option 9 deal with comparing things, to know if they are the same value?
https://
dbooth: Sounds like we have converged for handling nulls, on using a bnode with a type sentinal. Which type for null flavor?
erich: I recommend we use dicom null flavors.
detlef: Agreed.
detlef: json null is used when a number is missing.
… In other contexts, an empty string is used.
dbooth: Do we want to use a separate empty-string-null vs a numeric-null?
eric: If we don't distinguish between them, it might make round tripping harder.
… If the spec is complete enough to know the types of all properties, and no property that allows both numeric and string, then we could use that for round tripping.
erich: The dicom:vr is always there to indicate the type
… Option 5 may work better for the general case, in dealing w that.
… Certain properties are required, so empty string is used if you don't have a value.
eric: Suspect we need to do a survey of the VRs
… Could decide what we want as a null standoff.
… Then pospone the question of whether to use a single top null type vs two.
… Then do a survey on the VR types. If you could do it over, would you use emptry string for null?
… And can we use microparsing to reconstruct the empty string or numeric null
ACTION: Erich to look at VR types to see how they map to xsd datatypes
ADJOURNED