[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] Finding a common proposal..
Patrick Durusau <patrick@durusau.net> wrote on 12/06/2006 11:36:45 AM: > Bruce, > > Bruce D'Arcus wrote: > > > > > On Dec 6, 2006, at 10:51 AM, Patrick Durusau wrote: > > > >>> But let's be clear: when you move the metadata out of the content, > >>> you lose other functionality; for example, the ability for the user > >>> to be able to access specific chunks of content as > >>> metadata-enhanced; imagine being able to hover over a span of > >>> metadata-enhanced text that represents a client -- "Jane Doe" -- and > >>> having the application display additional information about them. > >>> > >> Sorry, I don't see why you would say that? Where is the loss of > >> functionality? > > > > > > Heh, good point :-) > > I do try. ;-) > > > > > This is a simple example that doesn't show what I mean (as I said, > > long day yesterday!). > > > > But say if you have a more complex statement (or series of them) in > > the text -- "Patrick is attending the XML2006 conference" -- and both > > the subject ("Patrick") and the object ("XML2006 conference") are > > resources with additional metadata (you have your vCard embedded in > > the package). If you have that triple in the package, then the string > > "Patrick" isn't going to be identified as a discrete metadata object > > in the content file. Now, the entire span or field might get > > highlighted and you could then access that further information, but it > > wouldn't be directly accessible from the text. > > > Err, but aren't you confusing the content of the text with its > representation in metadata? > > Yes, I have a complex statement (or a series of them) in the text: > "Patrick is attending the XML2006 conference." and I mark Patrick and > XML2006 conference separately with spans. Those spans point to those as > resources in the metadata file. The triple in question, my attending the > XML conference is represented separately from those two resources. One > of the things that an interface could do is show all the triples in > which those resources participate. > > Or to put it another way, why can't "Patrick" be represented as the > object of metadata? Is that some limitation of RDFa? Or just a > convention in terms of how people think about writing triples based upon > particular content? "Patrick" can be a resource or a literal. The resource case: <a rel="ex:attendee" href="#patrick">Patrick</a> The literal case: <span property="ex:attendee">Patrick</a> It's not a limitation of RDFa. I think it was just the example that Bruce was trying to make. > > Afterall, Patrick may appear in the document a number of times and I > would be hard pressed to think of a reason why metadata for Patrick > should be replicated in every triple where Patrick occurs as a resource. If you use a literal, then we'd need a convention to hook the metadata up. But if we used a resource, then we only need one copy of the metadata. > > My impression is that triples can reference other triples, if you insist > on representing Patrick as a triple so that would give me one triple for > Patrick that is referenced from all the other triples that need to make > use of it. So I attach my vCard only once and it is available any time > someone sees metadata for Patrick. triples can reference other triples (sort-of), it's called reification, but I don't think that's what you are asking. I think you meant resources, but anyways, what you said is right if you replace s/triple/resources for all triples in the above paragraph except for the first. > > Hope you are having a great day! Better than others this month. Thanks! > > Patrick > > > That's all I mean. > > > > But thanks for clarifying. > > > >> Actually I have been told there are advantages to having separate > >> files, even though a little bit harder with XSLT. You have all the > >> notes, for example, in a separate file which enables them to be > >> processed separately and without a larger content model than > >> necessary. Thinking that with metadata there might be similar > >> advantages. > > > > > > Exactly. It is indeed analogous (and in an ideal blank slate world, > > notes and comments could be understood as metadata). > > > >> Where in a medical situation I want to extract all the metadata from > >> an entire store of documents for navigational purposes, say all the > >> times Doctor X entered a prescription for valium for patient Y. > >> Should not be necessary for me to process all the document content to > >> get that answer. If the metadata resides in content.xml, I do. > > > > > > Yes, also right. There is a design trade-off. I (and I think Elias) > > are just saying that it's hard to legislate what ought to be > > context-specific design decisions. Generally keep the metadata out of > > the content file, but not disallow it. > > > > Bruce > > > > > > > > > > -- > Patrick Durusau > Patrick@Durusau.net > Chair, V1 - Text Processing: Office and Publishing Systems Interface > Co-Editor, ISO 13250, Topic Maps -- Reference Model > Member, Text Encoding Initiative Board of Directors, 2003-2005 > > Topic Maps: Human, not artificial, intelligence at work! > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]