|
Size: 3673
Comment:
|
← Revision 15 as of 2010-03-17 13:12:31 ⇥
Size: 2067
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| === doms:ContentModel_DOMS === ContentModel_DOMS is the root of the content model inheritance tree. All content models derive from this model. As all data objects in DOMS must have a content model, all data objects must adhere to the restrictions defined in this content model. |
== doms:ContentModel_DOMS == !ContentModel_DOMS is the root of the content model inheritance tree. All content models derive from this model. As all data objects in DOMS must have a content model, all data objects must adhere to the restrictions defined in this content model. |
| Line 4: | Line 4: |
| All subscribing objects must have a "doms-relations:hasLicense" relation to a object of "doms:!ContentModel_License". Also, it must have one or more "doms-relations:isPartOfCollection" relations to objects of "doms:!ContentModel_Collection". | |
| Line 5: | Line 6: |
| The ONTOLOGY datastream. {{{ <rdf:RDF xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://doms.statsbiblioteket.dk/relations/default/0/1/#"> |
All subscribing objects must have the following datastreams "DC", "POLICY" and "RELS-EXT". The "DC" stream must conform to the schema defined in the datastream "DC_SCHEMA", in "doms:!ContentModel_DOMS". This schema handles two major tasks. Firstly, it gives a xsd schema for the contents of the "DC" datastream, to validate the datastream against. Secondly, it introduces an order of the elements, and specify minOccurs and maxOccurs for each of them. This last task is an addition to the real dublin core standard, but documents conforming to this requirement will always be valid in the real standard as well. The "dc:title" element must always be present exactly once. This is both a requirement from the schema, and from the data model. All objects must have a title, stored in "dc:title" in the "DC" datastream. It is, of course, possible to redefine the "DC" datastream, as specified in FedoraTypeChecking, and thereby provide it with a new schema. If so, the contents of the datastream should be valid for both the schemas. |
| Line 13: | Line 9: |
| <owl:Class rdf:about="info:fedora/doms:ContentModel_DOMS"> | The use of the "POLICY" stream is defined in FedoraLicensePolicies. The "AUDIT" stream is detailed in DomsAuditTrail. |
| Line 15: | Line 11: |
| <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="isPartOfCollection"/> <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="isPartOfCollection"/> <owl:allValuesFrom rdf:resource="info:fedora/doms:ContentModel_Collection"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="hasLicense"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="hasLicense"/> <owl:allValuesFrom rdf:resource="info:fedora/doms:ContentModel_License"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:ObjectProperty rdf:about="isPartOfCollection"/> <owl:ObjectProperty rdf:about="hasLicense"/> </rdf:RDF> }}} In humanreadable format it says that all subscribing objects must have a "doms-relations:hasLicense" relation to a object of "doms:ContentModel_License". Also, it must have one or more "doms-relations:isPartOfCollection" relations to objects of "doms:ContentModel_Collection". DS-COMPOSITE datastream. {{{ <dsCompositeModel xmlns="info:fedora/fedora-system:def/dsCompositeModel#" xmlns:schema="http://doms.statsbiblioteket.dk/types/dscompositeschema/0/1/#"> <dsTypeModel ID="DC"> <form MIME="text/xml"/> <extensions name="DOMS"> <schema:schema type="xsd" datastream="DC_SCHEMA"/> </extensions> </dsTypeModel> <dsTypeModel ID="POLICY"> <form MIME="text/xml"/> </dsTypeModel> <dsTypeModel ID="STATE"> <form MIME="text/xml"/> <extensions name="DOMS"> <schema:schema type="xsd" datastream="STATE_SCHEMA"/> </extensions> </dsTypeModel> <dsTypeModel ID="RELS-EXT"/> </dsCompositeModel> }}} In human readable format, this say that all subscribing objects must have the following datastreams "DC", "POLICY", "STATE" and "RELS-EXT". The "DC" stream must conform to the schema defined in the datastream "DC_SCHEMA", in "doms:ContentModel_DOMS". The "STATE" stream must conform to the schema in datastream "STATE_SCHEMA" in "doms:ContentModel_DOMS". To understand the use of the "STATE" datastream, see the FedoraTransactionsReplacement. The use of the "POLICY" stream is defined in FedoraLicensePolicies. The "AUDIT" stream is detailed in DomsAuditTrail. The DC_SCHEMA stream is just an xml schema and looks like this -- REF to OAIDUBLINCORE XXXXX Regard this {{{ }}} |
All subscribing object can have a "doms-relations:isTemplateFor" relation to a object of "fedora-model:!ContentModel-3.0", i.e. to a content model. This marks the object as a template for this content model. This relation is a subclass of "fedora-model:hasModel", so it naturally implies that the object also has the content model. For further on templates, see FedoraObjectTemplates |
doms:ContentModel_DOMS
ContentModel_DOMS is the root of the content model inheritance tree. All content models derive from this model. As all data objects in DOMS must have a content model, all data objects must adhere to the restrictions defined in this content model.
All subscribing objects must have a "doms-relations:hasLicense" relation to a object of "doms:ContentModel_License". Also, it must have one or more "doms-relations:isPartOfCollection" relations to objects of "doms:ContentModel_Collection".
All subscribing objects must have the following datastreams "DC", "POLICY" and "RELS-EXT". The "DC" stream must conform to the schema defined in the datastream "DC_SCHEMA", in "doms:ContentModel_DOMS". This schema handles two major tasks. Firstly, it gives a xsd schema for the contents of the "DC" datastream, to validate the datastream against. Secondly, it introduces an order of the elements, and specify minOccurs and maxOccurs for each of them. This last task is an addition to the real dublin core standard, but documents conforming to this requirement will always be valid in the real standard as well. The "dc:title" element must always be present exactly once. This is both a requirement from the schema, and from the data model. All objects must have a title, stored in "dc:title" in the "DC" datastream. It is, of course, possible to redefine the "DC" datastream, as specified in FedoraTypeChecking, and thereby provide it with a new schema. If so, the contents of the datastream should be valid for both the schemas.
The use of the "POLICY" stream is defined in FedoraLicensePolicies. The "AUDIT" stream is detailed in DomsAuditTrail.
All subscribing object can have a "doms-relations:isTemplateFor" relation to a object of "fedora-model:ContentModel-3.0", i.e. to a content model. This marks the object as a template for this content model. This relation is a subclass of "fedora-model:hasModel", so it naturally implies that the object also has the content model. For further on templates, see FedoraObjectTemplates