[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] Minor fixes on the metadata manifest
Much have been clarified after the call about the manifest, here a summary: Svante Schubert wrote: > Some problems found in the metadata manifest and suggestions how to > fix them: > > 1) > Adding NamedGraph to the mm:Entry, as rdf:type not possible in a typed > node (see. > http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-typed-nodes). > But we would simply rename Entry to NamedGraph and we archieved the same. Multiple types are not a problem and the name should remain Entry, as there might be even other non RDF/XML, where metadata should be attached to. > > 2) > I realized have not added the document base ID to the spec so far. It > could be: > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> > <rdf:Description rdf:about="."> > <rdf:type > rdf:resource="http://docs.oasis-open.org/office/2007/03/meta/manifest#Manifest"> > > > <mm:baseId>urn:odf:122015dd-e58e-411f-8c3e-dd0b6d7be7d6</mm:baseId> > .. > > Which is similar to the typed node: > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:mm="http://docs.oasis-open.org/office/2007/03/meta/manifest#"> > <mm:manifest mm:baseId="urn:odf:122015dd-e58e-411f-8c3e-dd0b6d7be7d6"> > ... > > 3) We had in every entry (now NamedGraph) a type. The idea was to > specify the problematic the plug-in is solving by the type (e.g. VCard). > Although this not our direct scope as it is already application logic, > it is necessary for the plug-ins to 'find' their RDF/XML, after a > document is loaded ( they should not rely on file names). > > The question arises: What is the relation between this type and a > NamedGraph (in RDF/XML always a file)? > > Let's examine the following scenario: > A plug-in uses an address book with a NamedGraph/File with VCard > information and a citation plug-in would use a NamedGraph/File with > VCard information in the same document. > For me as a user, I do not want to have every VCard entry of the > citation in my address book! > > Therefore the relation is: one type can have multiple NamedGraphs. > To underline this I would suggest to bundle a set of NamedGraphs to > build up a hierarchy. This is not necessary, multiple types can solve this problem: <mm:Entry rdf:about="http://SOME-NAMED-GRAPH" m:full-path="meta/vcard.rdf"> <rdf:type rdf:resource="http://www.w3.org/2006/vcard/ns#" /> <rdf:type rdf:resource="http://example.org/addressbook/else#" /> </mm:Entry> For our example: The citation plug-in might look for two types vcard and citation, the addressbook for vcard and addressbook. > > 4) > We have the idea the binding between RDF statements and ODF elements > is made by ODF related RDF in the various RDF/XML. > Florian would be happy, if we would move these bindings as > sub-elements of an entry (NamedGraphs). > I support this idea, as the binding via xml:id between the RDF/XML > files and the Office XML files is only in one place. We agreed to move the binding between IRIs used in RDF/XML to ODF elements from the various RDF/XML files to the metadata manifest and further find out that we would save us a lot of problems, if we would require a unique xml:id, we might call odf:id. We now agreed on the new namespace prefix odf: - Where the odf namespace describes the type of RDF resources from the ODF package (e.g. files, elements, tables, heading, etc..). Florian and I will work out an example for the metadata manifest proposal that has been discussed on today's call and propose it ASAP to the list. A nice week-end to all of you, Svante
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]