Ontology for marking data formats and associating them with validators, parsers, serializers, and visualizers. Data Ontology Parser Super class for resources that can parse data; for example, given the relations: MyDataFormat rdfs:subClassOf data:DataFormat myData rdf:type MyDataFormat myData data:hasParser myParser Sending the URI of myData to myParser should parse the data. For example, given the format FASTA (http://en.wikipedia.org/wiki/FASTA_format), a parser may create objects with rdfs:comment set to the FASTA comment line (lines starting with '>') and tag the sequence as a Sequence Ontology type. Another parser may attempt to extract the species name and gene information from the '>' header, so it may parse these items into semantically tagged taxon and gene properties. Thus a single data URI may be associated with different parsers for different purposes. There is no requirement that parsers return semantically tagged RDF/XML. Indeed, in many cases it is useful if a parser does not return RDF/XML, but returns data itself (e.g., as text value, image file, etc.). For HTTP responses, MIME types may be useful. Parsers are free to define their mode of invocation and behavior. Root Data class. Data Accessor Super class for resources that are helper or gateway resources to accessing data. In this simplest case, this is just indirection to another URI where the data resides; in other cases, it may entail user authentican and authorization. For example, given the relations: MyDataFormat rdfs:subClassOf data:DataFormat myData rdf:type MyDataFormat myData data:hasAccessor myAccessor Sending the URI of myData to myAccessor should act as a gateway to the data. Alternatively, "myData" could be a blank node and indirection to the data would be via the value of data:hasAccessor. There are no standards on how accessors allow access to the data. The simplest case is indirection where a HTTP GET on the accessor's value returns the data. Another simple case is where the accessor is the data URI, and there is no data:hasAccessor property, or the property points back to its own subject. Accessors are free to define their mode of invocation and behavior. Super class for resources that can validate data; for example, given the relations: MyDataFormat rdfs:subClassOf data:DataFormat myData rdf:type MyDataFormat myData data:hasValidator myValidator Sending the URI of myData to myValidator should check the data for compliance against the type MyDataFormat. There are no standards on how validators signal valid or invalid data. Validators are free to define their mode of invocation and behavior. Validator Data Format Super class of the data itself in a particular format. It is used to tag resources as belonging to a specified data format as well as presenting a mechanism for linking validators, parsers, serializers, and visualizers to the resource. Specific formats are built by subclassing these classes; e.g.: seq:FASTA rdfs:subClassOf data:DataFormat. For data that is large in volume, or inherently binary, a useful pattern is to not serialize the data in OWL, but to type its URL with a subClass of data:DataFormat and then associate it with helper resources such as parsers, validators, and so forth. For example, the URI of a text file could belong to both classes seq:Sequence and seq:FASTA, tagging the type of data and its format respectively (e.g., a DNA sequence in FASTA format, where seq:FASTA is a rdfs:subClassOf data:DataFormat). The resource may also have the predicates data:hasParser and data:hasValidator each pointing to a parser and validator for the FASTA sequence. Possibly these two URIs are the same. The actual sequence data would be at the resource itself. Alternatively, the sequence data could be serialized as the value of the datatype property data:literalData or custom user-defined subproperty. The owl:minCardinality constraints of zero (0) annotationally tie this class to optional predicates, without making a logical requirement that such predicates be instantiated. 0 Serializer Super class for resources that can serialize data; for example, given the relations: MyDataFormat rdfs:subClassOf data:DataFormat myData rdf:type MyDataFormat myData data:hasSerializer mySerializer Sending the URI of myData to mySerializer should serialize (write out) the data. There is no requirement that serializers are restricted to OWL RDF/XML. Serializers are free to define their mode of invocation and behavior. has Output Processor A predicate for associating an output writer with a data object. The data:hasOutputProcessor predicate is an objectProperty (instead of a datatypeProperty with range xsd:anyURI) so that the object of the predicate can be semantically tagged within the graph itself. has Data A pointer to the data from an external object. The rdfs:range of data:hasData is data:DataFormat, which is the rdfs:domain of data:hasAccessor, data:hasParser, data:hasSerializer, data:hasValidator, and data:hasVisualizer; thus allowing the association of data with a format and processing tools. To identify serialized data as a property value, see data:literalData. A predicate for associating a serializer with a data object; for example, a link to an XML serializer. Serialization is the process "writing out" the data in a format independent of machine architectures. has Serializer A predicate for associating a parser with a data object; for example, a link to a FASTA parser. A parser "reads in" data and constructs it into a model or data structure. has Parser A predicate for associating a validator with a data object; for example, a link to a FASTA validator. A validator checks the validity or compliance of the data or its format to some standard. The data:hasValidator predicate is a subPropertyOf both data:hasInputProcessor and data:hasOutputProcessor. has Validator Root property for all data: object properties object Property A predicate for associating an accessor with a data object; for example, a link to user authentican and authorization. One model is where the subject of data:hasAccessor--a node of rdf:type data:DataFormat--is a blank node, and access to the data is via the object (the value) of the data:hasAccessor property. In this manner data:hasAccessor can be used to model data indirection. has Accessor has Input Processor A predicate for associating an input reader with a data object. The hasInputProcessor predicate is an objectProperty (instead of a datatypeProperty with range xsd:anyURI) so that the object of the predicate (e.g., a Parser) can be semantically tagged within the graph itself. literal Data Super property to identify serialized data. For example, the pseudo statements: MyDataFormat rdfs:subClassOf data:DataFormat mySequence rdf:subPropertyOf data:literalData myData rdf:type MyDataFormat myData mySequence "ACTGCAGTGGATCG" myData data:hasParser myParser allows programmatic association of the parser at myParser to with the serialized data (the value of mySequence) required for parsing. Note that the property is an owl:FunctionalProperty; i.e., for any given subject with this property, it can only have one instance with a value (or all instances have a semantically equivalent datatype value). By inference, this must also apply to all subproperties. This property is functional in the same manner that its subject can have at most one URI (for non-literal data). It also ensures that there is no ambiguity as to composition of literal data (in the case of multiple property values) and how helper resources (parsers, serializers, etc.) should act on multiple, un-ordered instances of literal data. Root property for all data: datatype properties datatype Property