[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Thoughts on use case draft
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]