The OWL DL ontology contains the attributes defined by DICOM. It was generated using the attribute dictionary from the pydicom Python module (http://code.google.com/p/pydicom/) and by parsing the macro, module and information object definitions found in part PS 3.3 of the DICOM standard. A tool that extracts metadata out of DICOM files using this ontology can be found at https://github.com/Bonubase/dicom2rdf Official attribute URIs ----------------------- The official attribute URIs use two equivalent variants of fragment identifier: #Tag.. or (owl:sameAs) # and is the upper case hexadecimal group and element number (4 hex digits each) of the attribute. is the keyword assigned by DICOM to the attribute, if available. Private attribute URIs ---------------------- Private data element attributes with odd group number and element number > 0x1000 use these fragment identifiers: #PTag... is the element number & 0xff (& = logical and). is the normalized identification code (value of tag , - where is the element number right-shifted by 8 bits). The normalized form of the implementor identification code is produced by removing all whitespace, encoding it with UTF8 and escaping anything not a letter, digit or '_.-/' using a $xx escape (Python function urllib.quote() with % replaced by $ in the result). Feel free to use private attribute URIs that are not defined in the ontology document. Attribute ranges ---------------- The ranges of the attributes are defined by their DICOM value representations (VR): -Textual VRs (AE,CS,LO,SH,LT,ST,UT,PN) should be represented by plain literals. FF should be replaced by \r\n\r\n and ESC should be replaced by the unicode replacement character to enable RDF/XML serialization. PN (Personal Name) values consist of several delimited components and should not be decomposed for the attributes of the ontology with VR PN. More popular attributes like foaf:familyName and foaf:givenName can be used for the components if the attribute applies to the corresponding person. -Integer VRs (IS,SL,SS,UL,US,AT) should be represented by xsd:long (even if the VR defines them as int or short - to simplify SPARQL querying). -Decimal/Floating point VRs (DS,FL,OF,FD) should be represented by xsd:double (even if the VR defines them as float - to simplify SPARQL querying). -VRs representing time (DA,TM,DT,AS) are represented as xsd:date, xsd:time, xsd:dateTime and xsd:duration. DICOM has a notion of approximate dateTime or time: You start with the year/hour and leave out more specific elements if they are unknown. The information about what is not known is sacrificed with this representation in favor of usability and performance of xsd:dateTime and xsd:time. -The UID VR (UI) should be represented by the corresponding urn:oid: URI. -The sequence VR (SQ) should be represented by a http://purl.org/co/List -The unknown VR (UN) should be represented by one of the above types if the application knows the VR implicitly or by a plain literal if the VR is not known and the actual value is within the ASCII range. -The OB and OW VR should be represented by individuals (not literals) with no restrictions on modelling. Attributes that can have multiple values (value multiplicity!=1) have range http://purl.org/co/List. The list items have the type corresponding to the VR from the list above. Attribute domains ----------------- DICOM attributes are organized into macros and modules of several attributes. Modules are organized into information object definitions (IOD), describing one or more real world objects called information entities (IE). The standard defines what IE (real world entity) a module describes in every IOD. Therefore, the domains for many attributes are one or more information entity classes like Patient, Study, Series, Image. In most cases, the attributes do *not* apply to the DICOM files or information objects. The URIs of information entity classes use #IE. fragment identifiers where is the name of the information entity with whitespaces removed. If you want to describe the dicom files and the IEs, you can connect both with properties like dcterms:subject. The relations connecting the IEs with each other (e.g. Patient *has* Study) will be added to the ontology soon. DICOM sequences --------------- Sequence attributes in DICOM allow nesting of data. They connect things with sequences of one or more sequence items. A sequence item is a set of attribute/value-pairs and does not necessarily correspond to an information object definition. It can also represent some kind of real world entity that is only implicitly defined by DICOM or some kind of abstract entity created by the particular organization of information in DICOM. To resolve this messy situation and create a clean knowledge representation for information within sequence items is a gigantic task nobody has tried yet. Therefore, this ontology regards sequence items as independent entities and the attributes within a sequence item apply to the sequence item (if the sequence item happens not to be another information object). Every sequence attribute has a corresponding class of possible sequence items with the following fragment identifier: #SequenceItem. or (owl:sameAs) #SequenceItem.Tag.. or #SequenceItem.PTag... The part after "SequenceItem." is identical with the attribute fragment identifier. The object of a sequence attribute should be a http://purl.org/co/List with the sequence items as list members.