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: bibliographic examples, and a comprehensive demo


Hi All,

When we talked on Thursday, I said I'd post some example bibliographic 
data. I don't actually recall exactly what I had in mind, but as I got 
going on this, I found it hard to stop. But given I have other 
deadlines, I feel I must turn to other things.

I ended up basically implementing an almost complete draft (in code) of 
what I have in mind because that was the only way I felt I could really 
show what I'm talking about WRT to extensibility.

See attached archive, which includes example metadata, manifest tweaks, 
and RELAX NG schemas.

Basic idea is:

1)  a generic metadata validator

2)  Default modules to describe agents (vcard) and all kinds of general 
document stuff (DC, DCQ), which can be reused in custom schemas

3)  bibliographic example, which reuses wherever possible, and only 
creates a few specific properties where needed

So, for example, the included meta.xml files (except for the document 
one, which is more complicated because of the meta:* legacy concerns) 
validate against the generic schema.

The XSLT example (in the "code" directory) is the simplest thing I 
could figure out that I could implement pretty quickly to show what I 
want. What is does it iterate through the manifest looking for metadata 
files, and then processes each of them for display.

Worth noting that both the core schema and the XSLT have only the most 
generic logic to validate and display this data. Repeat: the logic is 
generic.

I doubt the output is totally valid XHTML (I know, bad!), but it does 
show the data clearly enough, at least in my Mozilla-based browser.

Not at all finished, but hopefully gives a more concrete sense of what 
I'm advocating.

I've not really exploited the relational linking of RDF in the example 
file, but this ...

   <b:Reference rdf:about="x">
     <b:author>
       <!-- borrow vcard module -->
       <v:VCard>
         <v:n>
           <v:Name>
             <v:given-name>Jane</v:given-name>
             <v:family-name>Doe</v:family-name>
           </v:Name>
         </v:n>
       </v:VCard>
     </b:author>

... of course, could easily be normalized like so:

   <b:Reference rdf:about="x">
     <b:author rdf:resource="tag:person:x"/>

What this means from more a more use-case perspective, of course, is 
that there are no artificial walls between the data.

For comparison, here is what Open XML bibliographic data looks like:

<http://www.users.muohio.edu/darcusb/images/cites/oxml-bib-source.jpg>

What I am advocating is roughly similar, but:

1)  more powerful (MS's model is totally flat, aside from the 
contributor stuff)
2)  more international-friendly (because of vcard's name model, it's 
sort-string property, etc.)
3)  more standard (reuses almost everything, rather than reinvent).
4)  consistent with the rest of ODF metadata (as I am defining it)
5)  allows rich extension (through the general rules)

On # 1, for example, the MS schema won't be able to handle the example 
data I have of a republished book. I could point out a lot of other 
practical limitations of MS's flat model.

Am happy to answer any questions of course.

I should note that I probably can't make Thursday's call (and in fact, 
won't be able to make it for the indefinite future, so maybe we can see 
if we can change the time?), so list may be better.

Bruce

odf-rdf-demo.zip




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]