[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: summing up my requirements
So we didn't really come to any conclusions about the requirements discussion yesterday, but at a more appropriately high-level, I think the core of my argument is metadata in ODF (I guess defined as descriptions of document content, as opposed to maybe more custom processing solutions) must be: 1) extensible Here, rather than rewrite, I'd just cite the RSS 1.0 spec: > Namespace-based modules allow compartmentalized extensibility. This > allows RSS to be extended: > > * without need of iterative rewrites of the core specification > * without need of consensus on each and every element > * without bloating RSS with elements the majority of which won't > be used in any particular arena or application > * without naming collisions Right. 2) allow ad-hoc mixing This is sort of a subset of 1 in that true extensibility implies this to me, but the idea is that core metadata (which might be just included modules) needs to be able to be mixed with extension metadata in unforeseen ways. Example: I include contact records encoded in vCard. A bibliographic or document description must be able to refer to those metadata items without any particular programming logic. Can we agree on these goals? Really, they're pretty critical. It'll be hard to move forward without some consensus on this. On RDF: It's true these could be achieved without it, but you end up needlessly reinventing it (a la MS). You have to have a spec, then, to identify descriptions, another one to describe extension models, and another one to do linking. This is a BIG task, and going through all that would buy us nothing, I argue, over RDF. Let me just take the smallest of examples, using the above as use case: vcard: <v:VCard rdf:about="urn:x:1"> <v:fn>Jane Doe</v:fn> <v:n> <v:Name> <v:given-name>Jane</v:given-name> <v:family-name>Doe</v:family-name> </v:Name> </v:n> </v:VCard> Basic contact record in vCard. You can imagine a full record yourself, complete with address, etc. OK, let's say we want to refer to that from the main document metadata; it's as simple as: <dc:creator rdf:resource="urn:x:1"/> [note: there's some issues with whether this is good practice with dc:creator, but let's leave that aside] The critical point to understand here is that resources are atomic bits of metadata, identified with URIs. They in turn consist of simple lists of (namespaced) properties: the triples. This is the "directed graph" that people talk about, and it's really better to think of it visually, as a graph of relationships. If you like, you can think of these as relational databases of sorts, but in XML. The two of these together mean that you achieve the two goals above (extensibility and ad hoc mixing/linking). From a processing standpoint, it really doesn't make any difference if you do the above, or instead just use anonymous containment. <dc:creator> <v:VCard> <v:fn>Jane Doe</v:fn> <v:n> <v:Name> <v:given-name>Jane</v:given-name> <v:family-name>Doe</v:family-name> </v:Name> </v:n> </v:VCard> </dc:creator> From the standpoint of RDF querying, for example, they are the same, and that's only because of the consistent model. And because of that consistent model, you can also account for it with XML tools. Indeed, I have a generic XSLT function I borrowed from Norm Walsh that resolves links this way. So this is what the two goals above look like in RDF. The bottom line is that good metadata support is very difficult. The more help we get by reusing existing standards, the better. Anyway, will try to post an example later. Bruce
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]