Fwd: Thoughts on use case draft

[Bruce D'Arcus <bruce.darcus@OpenDocument.us>]

 From John, who's having problems posting to this list ...

Begin forwarded message:

> From: John C Barstow <jbowtie@amathaine.com>
> Date: June 29, 2006 1:16:32 AM EDT
> To: office-metadata@lists.oasis-open.org
> Subject: Thoughts on use case draft
>
>
> While reading through the use cases draft, I had a few thoughts about
> possible implementation issues that I think might illuminate some 
> corner
> cases. Most of it probably isn't in scope at the moment (still doing 
> use
> cases) but I think it picks out some common themes. It also probably
> reveals more of my mental processes than is wise.
>
> =Location of metadata=
>  * Implicit metadata already exists in the form of certain elements and
> attributes like caption titles; how does this map to standard
> ontologies?
>  * Extrinsic metadata (document aware it exists) - in this case, I'd
> want to somehow embed a URI that points to this metadata. If I can
> resolve the URI, additional data becomes visible. If I can't resolve it
> then the data isn't visible. This is a way to handle scrubbing.
>  * Extrinsic metadata (document unaware it exists) - for this to be
> viable we need a way to address individual elements from outside the
> document. If I can create a URI that points to a specific image or
> paragraph I'm happy.
>  * Intrinsic metadata (about this document) - I need to be able to 
> embed
> arbitrary metadata and see it preserved. I expect this as a core
> requirement.
>  * Intrinsic metadata (about other documents) - Links are the obvious
> place for this, but I expect there are other places where we need to do
> this. For example, auto-generated documentation may include structured
> metadata about the source files.
>
> =Degree of support=
> * Explicit support for specific types of metadata would ideally be on a
> per-ontology basis. It's important to note that a single ontology may
> span multiple XML namespaces!
> * Implicit support - we should be able to document mappings of existing
> markup to standard vocabularies such as Dublin Core.
>
> =Specific use cases=
>
> ==Accessibility Information==
> Extrinsic metadata (document unaware) would be very interesting for
> supplying *missing* accessibility information to documents you can't
> edit. Intrinsic metadata (about other documents) could come in quite
> handy for linked content as it would allow a reader to make informed
> decisions before activating the link.
>
> ==Asymmetric metadata==
> Extrinsic metadata (document aware) seems the best bet here.
> Alternatively you have to start looking at encrypting portions of the
> document.
>
> ==Automatically generated metadata ==
> Lots of security implications here; really going to be
> implementation-specific issue, I think. However mappings to implicit
> metadata are needed to make this a viable option.
>
> ==Bibliographies and Citations==
> This is a great use case for calling out explicit support for a 
> specific
> ontology. People can then build support and tools around this support.
>
> ==Content Tagging==
> We might want to distinguish between tagging with formal, supported
> vocabularies vs informal vocabularies.
>
> ==Conversion Metadata==
> ==Mapping “MS Fields” to OpenDocument==
> ==Roundtrip improvement==
> I think these three are all the same use case. A converter can store
> conversion hints as intrinsic metadata (about this document) or in
> another document as extrinsic metadata (document aware) depending on 
> the
> workflow.
>
> ==Enhanced Search==
> This is probably best served by allowing arbitrary metadata as in most
> cases domain-specific knowledge is required.
>
> ==Intellectual Property==
> We probably need to tread lightly here - potentially explosive and may
> expand to encompass DRM debate.
>
> ==Metadata templates==
> I was thinking CSS selectors + n3 rules. Heh.
> This is actually a very core use case from my perspective; feeds 
> forward
> into the "Conversion Metadata" case.
>
> ==Ontology Validation==
> Very tricky. Validation generally requires a closed-world assumption,
> while many ontologies have an open-world assumption.
>
> ==Realtime Collaborative Editing==
> Open-world assumptions are your friend.
>
> ==Revision metadata==
> Don't we have revision control systems for this?  I'm a bit leery of
> embedding the information directly into the document; rather have a
> pointer to the RCS interface.
>
> ==Security metadata==
> While encryption is outside the scope of ODF, we need to think about 
> how
> metadata wil be canonicalised to make encryption viable.
>
> ==Workflow Management==
> We should seriously look at XML Signatures as part of this use case; in
> which case defining canonicalisation will be needed.
>
>