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: Re: [office-metadata] Finding a common proposal..


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?

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.

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.

Hope you are having a great day!

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]