OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[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]