View source for Documentation/DevGuide/OfficeDev/RDF metadata

From Apache OpenOffice Wiki

← Documentation/DevGuide/OfficeDev/RDF metadata

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

---

You can view and copy the source of this page.

{{Documentation/DevGuide/OfficeDevTOC |OfficeDev2b=block |ShowPrevNext=block |PrevPage=Documentation/DevGuide/OfficeDev/OpenOffice.org Single Sign-On API |NextPage=Documentation/DevGuide/Text/Text Documents }} {{Documentation/DevGuideLanguages|Documentation/DevGuide/OfficeDev/{{SUBPAGENAME}}}} {{DISPLAYTITLE:RDF metadata}} __NOTOC__ <!--<idltopic>com.sun.star.rdf</idltopic>--> ODF 1.2 introduces a new metadata mechanism based on RDF. RDF expands to Resource Description Framework, and is an W3C standard. Please refer to the W3C for information about RDF: http://www.w3.org/RDF/ Especially the first 2 sections of the RDF Primer are required reading for understanding the (really quite simple) basic concepts of the RDF data model: [http://www.w3.org/TR/rdf-primer/ RDF Primer] If you like reading an in-depth specification, please refer to: [http://www.w3.org/TR/rdf-concepts/ RDF Concepts and Abstract Syntax] If you are interested in some motivational use cases, and an overview of the basic design from the ODF perspective, have a look at the [http://www.oasis-open.org/committees/download.php/34796/09-10-22-ODF-Metadata-Examples.odt ODF Metadata examples document]. The {{PRODUCTNAME}} implementation of the RDF data model lives in the <idlmodule>com.sun.star.rdf</idlmodule> module. === Nodes === <!--<idltopic>com.sun.star.rdf.XNode;com.sun.star.rdf.XResource</idltopic>--> First, there are the basic RDF ''node'' types: {|border="1" cellpadding=4 style="border-collapse:collapse;" |-bgcolor=#EDEDED !RDF node type !Interface !Service |- |node |<idl>com.sun.star.rdf.XNode</idl> | |- |literal |<idl>com.sun.star.rdf.XLiteral</idl> |<idl>com.sun.star.rdf.Literal</idl> |- |resource |<idl>com.sun.star.rdf.XResource</idl> | |- |URI |<idl>com.sun.star.rdf.XURI</idl> |<idl>com.sun.star.rdf.URI</idl> |- |blank node |<idl>com.sun.star.rdf.XBlankNode</idl> |<idl>com.sun.star.rdf.BlankNode</idl> |} <source lang="idl"> interface XNode { [readonly, attribute] string StringValue; }; </source> The interface <idls>com.sun.star.rdf.XResource</idls> is only necessary to separate the literal, which is not a ''resource'', from the blank node and URI. === Literals === <!--<idltopic>com.sun.star.rdf.XLiteral;com.sun.star.rdf.Literal</idltopic>--> Literals are represented by the service <idl>com.sun.star.rdf.Literal</idl>. <source lang="idl"> interface XLiteral : XNode { [readonly, attribute] string Value; [readonly, attribute] string Language; [readonly, attribute] XURI Datatype; }; service Literal : XLiteral { create( [in] string Value ); createWithType( [in] string Value, [in] XURI Type ); createWithLanguage( [in] string Value, [in] string Language ); }; </source> This service has three constructors, one for every distinct kind of literal in RDF. The simplest kind of literal is a plain value. A literal may also have a data type, which is represented by an URI. Such literals are called ''typed literals''. The [http://www.w3.org/TR/xmlschema-2/ W3C XMLSchema Part 2] specification contains several widely used data types such as numbers, booleans, dates, and many more. It is also possible to create a literal with a specific language. This makes it possible to have a multi-lingual RDF graph, where statements are repeated with the same subject and predicate, but different objects that contain the same text content in different languages. === URIs === <!--<idltopic>com.sun.star.rdf.XURI;com.sun.star.rdf.URI</idltopic>--> In RDF, URIs are used to denote resources. URIs may be used as subjects or objects of a statement. In contrast with other node types, URIs may also be used as the predicate of a statement. <source lang="idl"> service URI : XURI { create( [in] string Value ) raises( lang::IllegalArgumentException ); createNS( [in] string Namespace, [in] string LocalName ) raises( lang::IllegalArgumentException ); createKnown( [in] short Id ) raises( lang::IllegalArgumentException ); }; </source> The URI service has constructors <idlm>com.sun.star.rdf.URI:create</idlm> and <idlm>com.sun.star.rdf.URI:createNS</idlm>, which allow for creating an URI from a string. These two constructors are very similar, but <code>createNS</code> allows splitting the parameter into two parts, which may be useful when creating several URIs that share a prefix because they belong to the same vocabulary. There are many URIs that are well-known because they are specified in various standards, such as XMLSchema datatypes, RDF concepts, OWL, and ODF. There is a convenient way to construct such URIs: using the <idlm>com.sun.star.rdf.URI:createKnown</idlm> constructor, together with constants from the <idl>com.sun.star.rdf.URIs</idl> constant group. <source lang="java"> rdf.XURI xContentFile = rdf.URI.createKnown(rdf.URIs.ODF_CONTENTFILE); </source> Of course, string literals would be easier to use, but unfortunately UNO IDL does not permit them. === Blank nodes === <!--<idltopic>com.sun.star.rdf.XBlankNode;com.sun.star.rdf.BlankNode</idltopic>--> The other kind of RDF node is the blank node, which is a resource, but in contrast to an URI, is not unique. Because blank nodes are not unique, you should only construct them with the <idlm>com.sun.star.rdf.XRepository:createBlankNode</idlm> method, not with the service constructor, and you should never use a blank node with a different repository than the one that created it. === Statements === <!--<idltopic>com.sun.star.rdf.Statement</idltopic>--> Using these nodes, RDF ''statements'' can be constructed, which are basically subject-predicate-object triples. <source lang="idl"> struct Statement { XResource Subject; XURI Predicate; XNode Object; /// the named graph that contains this statement, or <NULL/>. XURI Graph; }; </source> The subject of the statement is the entity that the statement is about. The subject must be either an URI or a blank node; a literal is not allowed. The predicate denotes what the relationship between the subject and the object is. In order to ensure that statements have a machine-readable semantics, only URIs are allowed as predicates. The object of the statement may be any kind of RDF node. If you put many statements together, and these statements share subjects and objects, then you will get a RDF ''graph''. === Graphs === <!--<idltopic>com.sun.star.rdf.XNamedGraph</idltopic>--> Graphs are represented by the interface <idl>com.sun.star.rdf.XNamedGraph</idl>. As the name implies, a ''named graph'' has a name, which is a URI. This is why the <idls>com.sun.star.rdf.XNamedGraph</idls> interface inherits from <idls>com.sun.star.rdf.XURI</idls>. {{Documentation/Note | This means that you can easily create RDF statements about named graphs.}} <source lang="idl"> interface XNamedGraph : XURI { XURI getName(); void clear() raises( container::NoSuchElementException, RepositoryException ); void addStatement( [in] XResource Subject, [in] XURI Predicate, [in] XNode Object) raises( lang::IllegalArgumentException, container::NoSuchElementException, RepositoryException ); void removeStatements( [in] XResource Subject, [in] XURI Predicate, [in] XNode Object) raises( container::NoSuchElementException, RepositoryException ); container::XEnumeration/*<Statement>*/ getStatements( [in] XResource Subject, [in] XURI Predicate, [in] XNode Object) raises( container::NoSuchElementException, RepositoryException ); }; </source> The individual methods will be discussed in subsequent sections. There is no service for a named graph, because named graphs always live in a repository. === Repository === <!--<idltopic>com.sun.star.rdf.XRepository;com.sun.star.rdf.XRepositorySupplier</idltopic>--> The repository is the centerpiece of the RDF API. It is defined in the interface <idl>com.sun.star.rdf.XRepository</idl>, and the service <idl>com.sun.star.rdf.Repository</idl>. <source lang="idl"> interface XRepository { XBlankNode createBlankNode(); XNamedGraph importGraph([in] /*FileFormat*/ short Format, [in] io::XInputStream InStream, [in] XURI GraphName, [in] XURI BaseURI) raises( lang::IllegalArgumentException, datatransfer::UnsupportedFlavorException, container::ElementExistException, ParseException, RepositoryException, io::IOException ); void exportGraph([in] /*FileFormat*/ short Format, [in] io::XOutputStream OutStream, [in] XURI GraphName, [in] XURI BaseURI) raises( lang::IllegalArgumentException, datatransfer::UnsupportedFlavorException, container::NoSuchElementException, RepositoryException, io::IOException ); sequence<XURI> getGraphNames() raises( RepositoryException ); XNamedGraph getGraph([in] XURI GraphName) raises( lang::IllegalArgumentException, RepositoryException ); XNamedGraph createGraph([in] XURI GraphName) raises( lang::IllegalArgumentException, container::ElementExistException, RepositoryException ); void destroyGraph([in] XURI GraphName) raises( lang::IllegalArgumentException, container::NoSuchElementException, RepositoryException ); container::XEnumeration/*<Statement>*/ getStatements( [in] XResource Subject, [in] XURI Predicate, [in] XNode Object) raises( RepositoryException ); /// executes a SPARQL "SELECT" query. XQuerySelectResult querySelect([in] string Query) raises( QueryException, RepositoryException ); /// executes a SPARQL "CONSTRUCT" query. container::XEnumeration/*<Statement>*/ queryConstruct([in] string Query) raises( QueryException, RepositoryException ); /// executes a SPARQL "ASK" query. boolean queryAsk([in] string Query) raises( QueryException, RepositoryException ); }; </source> A RDF repository is basically a set of named RDF graphs. The names of the contained graphs can be retrieved via the <idlm>com.sun.star.rdf.XRepository:getGraphNames</idlm> method. An individual graph can be retrieved via the <idlm>com.sun.star.rdf.XRepository:getGraph</idlm> method. A repository may be created as a stand-alone service, or it may be associated with a loaded ODF document. The graphs in a document repository correspond to streams in an ODF package, and thus the graph names consist of the URI of the ODF package and the relative path of the stream within the package. {{Documentation/Caution | For a document repository, you should not call the <idlm>com.sun.star.rdf.XRepository:createGraph</idlm>, <idlm>com.sun.star.rdf.XRepository:destroyGraph</idlm> or <idlm>com.sun.star.rdf.XRepository:importGraph</idlm> methods directly; instead, call the respective methods of <idl>com.sun.star.rdf.XDocumentMetadataAccess</idl>, as described below.}} Services that provide an RDF repository implement the interface <idl>com.sun.star.rdf.XRepositorySupplier</idl>. <source lang="idl"> interface XRepositorySupplier { XRepository getRDFRepository(); }; </source> === Document integration === <!--<idltopic>com.sun.star.rdf.XDocumentMetadataAccess;com.sun.star.rdf.XMetadatable</idltopic>--> The other main part of the RDF API is the integration in document models. This purpose is served by the interface <idl>com.sun.star.rdf.XDocumentMetadataAccess</idl>, which is implemented by the <code>Model</code> service of documents. Furthermore, there is the interface <idl>com.sun.star.rdf.XMetadatable</idl>, which allows document content entities to be used as subjects or objects in the methods that manipulate RDF graphs. <source lang="idl"> interface XMetadatable : XURI { [attribute] beans::StringPair MetadataReference { set raises ( lang::IllegalArgumentException ); }; void ensureMetadataReference(); }; </source> {{Documentation/Caution | The <idls>com.sun.star.rdf.XMetadatable</idls> interface has an attribute <idlm>com.sun.star.rdf.XMetadatable:MetadataReference</idlm>. This attribute is only meant to be set by import filters, such as the ODF import filter. Extensions should use <idlm>com.sun.star.rdf.XMetadatable:ensureMetadataReference</idlm>, or simply use a <idls>com.sun.star.rdf.XMetadatable</idls> as a parameter to <idlm>com.sun.star.rdf.XNamedGraph:addStatement</idlm>, which will automatically call <code>ensureMetadataReference()</code>.}} === Annotated text range === <!--<idltopic>com.sun.star.text.InContentMetadata</idltopic>--> The service <idl>com.sun.star.text.InContentMetadata</idl> allows to add annotations to a range of text. The range of text must be contained within a single paragraph, and annotations must not overlap (but they are allowed to nest). {{Documentation/Note | In essence, this is a <code>span</code> with a <code>xml:id</code>.}} <source lang="java"> text.XText = xDoc.getText(); text.XTextCursor xCursor = ... // position to where you want the annotation Object xMeta = xDocFactory.createInstance( "com.sun.star.text.InContentMetadata"); text.XTextContent xContent = (text.XTextContent) UnoRuntime.queryInterface(text.XTextContent.class, xMeta); try { xDocText.insertTextContent(xCursor, xMeta, true); } catch (lang.IllegalArgumentException) { // overlap? } </source> When the <code>InContentMetadata</code> is successfully inserted, you can add metadata by just using it as the subject or object of an RDF statement. <source lang="java"> rdf.XMetadatable xMetadatable = (rdf.XMetadatable) UnoRuntime.queryInterface(rdf.XMetadatable.class, xContent); rdf.XURI xComment = rdf.URI.createKnown(rdf.URIs.RDFS_COMMENT); rdf.XLiteral xObj = rdf.Literal.create("a most interesting description"); rdf.XNamedGraph xGraph = xDocRepository.getGraph(xMyGraphURI); xGraph.addStatement(xMetadatable, xComment, xObj); </source> === Metadata field === <!--<idltopic>com.sun.star.text.MetadataField</idltopic>--> There is a new text field that is explicitly designed for being used with RDF metadata: <idl>com.sun.star.text.textfield.MetadataField</idl>. In contrast with the <code>InContentMetadata</code>, where an ''existing'' range of text is being annotated with additional metadata, the metadata field allows for text content to be ''generated from'' RDF metadata. For example, a bibliography extension could use a metadata field to insert a citation. The user could tell the bibliography extension which citation format should be used, and the extension will generate the content of all the citation metadata fields based on this choice. The extension may use some bibliography database that may also be stored as an RDF graph. Metadata fields must be contained within a single paragraph, and must not overlap (but they are allowed to nest). To enable generating the content, the metadata field implements the <idl>com.sun.star.text.XText</idl> interface. <source lang="java"> text.XTextContent xMetafield = ... ; // get an inserted metadata field text.XText xMetafieldText = (text.XText) UnoRuntime.queryInterface(text.XText.class, xMetafield); xMetafieldText.setString(""); // clear the field: delete all content text.XTextCursor xCursor = xMetafieldText.createCursor(); xMetafieldText.insertString(xCursor, "field content", true); </source> Of course, you can not just insert plain text, but everything that you could insert into a paragraph. <source lang="java"> xCursor.gotoEnd(false); text.XTextContent xFootnote = ... ; // create and init footnote xMetafieldText.insertTextContent(xCursor, xFootnote, false); </source> Metadata fields have another interesting aspect: they can have a ''prefix'' and/or ''suffix'' text that is taken from one of the RDF graphs in the document. In this way you can create a metadata field with text content that is automatically displayed (non-editable) based on an RDF statement. <source lang="java"> rdf.XMetadatable xMetafield = ... ; // get an inserted metadata field rdf.XNamedGraph xGraph = xDocRepository.getGraph(xMyGraphURI); rdf.XURI xPrefix = rdf.URI.createKnown(rdf.URIs.ODF_PREFIX); xGraph.addStatement(xMetafield, xPrefix, "this text will be displayed as prefix content of the field"); </source> === Other document entities === In addition to the annotated text range and the metadata field, other document content entities implement the <idls>com.sun.star.rdf.XMetadatable</idls> interface as well. These entities can thus be used in RDF statements. The list of entities which can be thus annotated will grow in future releases of {{PRODUCTNAME}}. === Adding metadata to a document === The metadata support in ODF 1.2 allows for adding RDF graphs to an ODF package. Every RDF graph is stored as an <code>RDF/XML</code> stream in the package. There is a special RDF graph called the ''metadata manifest''. This RDF graph belongs to a document and enumerates all the files relevant for metadata, such as the individual RDF/XML files. This manifest graph is maintained by {{PRODUCTNAME}} itself; extension authors should not modify it directly, but use the interface <idl>com.sun.star.rdf.XDocumentMetadataAccess</idl>. In order to isolate different metadata users, every extension that wants to add metadata should create one (or several) own RDF graph(s). It is recommended to give the new graphs a ''type'' that identifies what kind of information is contained, especially if a well-known RDF vocabulary is used. With the method <idlm>com.sun.star.rdf.XDocumentMetadataAccess:addMetadataFile</idlm>, you can specify as many types as you want for a graph. <code lang="java"> rdf.XDocumentMetadataAccess xDMA = (rdf.XDocumentMetadataAccess) UnoRuntime.queryInterface(rdf.XDocumentMetadataAccess.class, xModel); rdf.XURI xType = rdf.URI.create("http://example.com/myextension/v1.0"); try { rdf.XURI xGraphName = xDMA.addMetadataFile("myextension/mygraph.rdf", new rdf.XURI[] { xType } ); rdf.XNamedGraph xGraph = xDMA.getRDFRepository().getGraph(xGraphName); } catch (container.ElementExistException e) { // filename exists? } </code> {{Documentation/Note| Choose a stream name that is unlikely to conflict with other extensions. The preferred suffix is <code>.rdf</code>.}} {{Documentation/Tip | The method <idlm>com.sun.star.rdf.XDocumentMetadataAccess:importMetadataFile</idlm> allows to import an existing RDF/XML file into the document RDF repository.}} Now you can simply insert RDF statements into the graph: <code lang="java"> rdf.XMetadatable xElement = ...; // some document content entity rdf.XURI xLabel = rdf.URI.createKnown(rdf.URIs.RDFS_LABEL); rdf.XLiteral xObj = rdf.Literal.create("a most interesting description"); xGraph.addStatement(xElement, xLabel, xObj); </code> === Reading metadata from a document === In order to read metadata that is stored in a document, query the RDF repository of the document. There are basically two ways to do this. One way is to use the getter methods at the named graph and repository interfaces. The method <idlm>com.sun.star.rdf.XRepository:getStatements</idlm> will return all statements in any graph in the repository that match the given parameters. But note that this is not necessarily what you want. Usually, an extension is only interested in the metadata it has itself inserted. Thus it is better to first get the graph(s) that the extension is interested in, and then only query those graphs via <idlm>com.sun.star.rdf.XNamedGraph:getStatements</idlm>. <code lang="java"> rdf.XDocumentMetadataAccess xDMA = (rdf.XDocumentMetadataAccess) UnoRuntime.queryInterface(rdf.XDocumentMetadataAccess.class, xModel); rdf.XURI xType = rdf.URI.create("http://example.com/myextension/v1.0"); rdf.XURI[] GraphNames = xDMA.getMetadataGraphsWithType(xType); for (rdf.XURI xGraphName : GraphNames) { rdf.XNamedGraph xGraph = xDMA.getRDFRepository().getGraph(xGraphName); // replace nulls with interesting URIs container.XEnumeration xResult = xGraph.getStatements(null, null, null); while (xResult.hasMoreElements()) { rdf.Statement stmt = (rdf.Statement) xResult.nextElement(); } } </code> The other way of getting information out of the repository is via the [http://www.w3.org/TR/rdf-sparql-query/ SPARQL query language]. The same considerations as above apply: by default, the result will contain information from all graphs in the repository. You can restrict the graphs via the <code>GRAPH</code> or <code>FROM</code> clauses. <code lang="java"> rdf.XDocumentMetadataAccess xDMA = (rdf.XDocumentMetadataAccess) UnoRuntime.queryInterface(rdf.XDocumentMetadataAccess.class, xModel); rdf.XURI xType = rdf.URI.create("http://example.com/myextension/v1.0"); rdf.XURI[] GraphNames = xDMA.getMetadataGraphsWithType(xType); if (GraphNames.length > 0) { String graphName = GraphNames[0].getStringValue(); String query = "CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <" + graphName + "> { ?s ?p ?o } . }"; container.XEnumeration xResult = xDMA.getRDFRepository().queryConstruct(query); while (xResult.hasMoreElements()) { rdf.Statement stmt = (rdf.Statement) xResult.nextElement(); } } </code> Besides the <code>CONSTRUCT</code> query shown above, there are also the methods <idlm>com.sun.star.rdf.XRepository:querySelect</idlm>, which returns a table of results, and <idlm>com.sun.star.rdf.XRepository:queryAsk</idlm>, which simply returns a <code>boolean</code>. There are different methods for the different query types because the return types differ. {{Documentation/Caution | Always use the query method that matches the query type.}} === Mapping from URIs to document entities === <!--<idltopic>com.sun.star.rdf.XDocumentMetadataAccess;com.sun.star.rdf.XMetadatable</idltopic>--> Note that for a document content annotation the RDF repository will only give you an URI in its results, not the actual document content entity. In order to map the URI to the document entity, use the <idlm>com.sun.star.rdf.XDocumentMetadataAccess:getElementByURI</idlm> method. <code lang="java"> rdf.XDocumentMetadataAccess xDMA = (rdf.XDocumentMetadataAccess) UnoRuntime.queryInterface(rdf.XDocumentMetadataAccess.class, xModel); rdf.XURI xElemURI = ... // query the document repository rdf.XMetadatable xElement = xDMA.getElementByURI(xElemURI); text.XTextContent xElemContent = (text.XTextContent) UnoRuntime.queryInterface(text.XTextContent.class, xElement); </code> {{Documentation/Tip | You can check if an URI refers to a document entity: it does if it has as a prefix the ''base URI'' of the document, which is available as the <idls>com.sun.star.rdf.XURI</idls> implementation of the document model. But please keep in mind that the document entity does not need to exist, because it may have been removed from the document.}} === Removing metadata from a document === The named graph supports the <idlm>com.sun.star.rdf.XNamedGraph:removeStatements</idlm> method, which removes all statements that match the parameters from the graph. {{Documentation/Note | There is no update operation. If you want to update an RDF statement, you have to remove the existing statement, and insert a new one.}} Also, there is the <idlm>com.sun.star.rdf.XNamedGraph:clear</idlm> method, which is equivalent to <code>removeStatements(null, null, null)</code>, and removes all statements from the graph. For removing whole metadata streams from an ODF document, there is the method <idlm>com.sun.star.rdf.XDocumentMetadataAccess:removeMetadataFile</idlm>. === Vocabulary === Some notes on RDF vocabularies; of course, a comprehensive discussion of RDF design is beyond the scope of this guide. {{Documentation/Caution | Do not use URIs based on the document base URI as properties. Properties should be independent of the location of the document.}} An important question when adding RDF metadata is: which vocabulary do you use? First, it is usually a good idea to re-use an existing vocabulary. This will improve the chances that other software, which also supports the existing vocabulary, is able to do something interesting and useful with the metadata that is added. For example, for basic datatypes you can use the types specified in [http://www.w3.org/TR/xmlschema-2/ W3C XMLSchema Part 2]. A well-known vocabulary for expressing social relations is [http://www.foaf-project.org/ Friend-of-a-Friend]. A directory of RDF schemata can be found at [http://schemaweb.info/ SchemaWeb]. Another useful resource might be [http://dbpedia.org/ DBPedia]. If you do not find an existing vocabulary that matches your use case, here are some hints for designing your own: The most important thing is that the URIs should really be unique. If you have a DNS domain, then that is quite easy to achieve: use URIs like <code>http://example.com/myvocabulary/v1.0/foo</code>. It is probably a good idea to use a versioned namespace prefix like <code>http://example.com/myvocabulary/v1.0/</code> for all URIs. The version component allows you to evolve the vocabulary to meet future requirements. Now you can use the versioned namespace prefix to denote the format, i.e., as a type for your metadata stream, making it easy to find. You can also create an actual HTML page to document the vocabulary at the URI. === Status === As of OOo version 3.2, RDF metadata is only supported in writer documents. The generic RDF parts of the API are all implemented. The document integration parts are not yet completely implemented: most elements do not support the <code>xml:id</code> that is required for use with RDF. The following elements can be annotated: {|border="1" cellpadding=4 style="border-collapse:collapse;" |-bgcolor=#EDEDED !ODF element !Service !description |- |<code>&lt;text:p&gt;</code> |<idl>com.sun.star.text.Paragraph</idl> |paragraph |- |<code>&lt;text:h&gt;</code> |<idl>com.sun.star.text.Paragraph</idl> |heading |- |<code>&lt;text:bookmark&gt;</code> |<idl>com.sun.star.text.Bookmark</idl> |bookmark |- |<code>&lt;text:bookmark-start&gt;</code> |<idl>com.sun.star.text.Bookmark</idl> |bookmark |- |<code>&lt;text:meta&gt;</code> |<idl>com.sun.star.text.InContentMetadata</idl> |annotated text range |- |<code>&lt;text:meta-field&gt;</code> |<idl>com.sun.star.text.textfield.MetadataField</idl> |text field whose content is generated from metadata |} {{PDL1}} [[Category:Documentation/Developer's Guide/Office Development]]

Return to Documentation/DevGuide/OfficeDev/RDF metadata.