Re: [office-metadata] Define a Mechanism to Associate Metadata withContent?

[Patrick Durusau <patrick@durusau.net>]

Bruce,

I think Florian will be joining us today and so we may get to the bottom 
of this one.

BTW, to paraphrase Big Daddy in Tennessee Williams play, "Cat on a Hot 
Tin Roof":

"When I'm confused I know I'm alive." ;-)

Hope you are having a great day!

Patrick

Bruce D'Arcus wrote:

>
> On Sep 13, 2006, at 9:56 AM, Patrick Durusau wrote:
>
>> Moreover, for example, both ODF and MSXML have sections, but they 
>> have different content models. From what I have been told, MSXML does 
>> not allow sections within sections, while that is possible in ODF.
>>
>> If I convert MSXML -> ODF, ok, but then if I edit the document in ODF 
>> and embed sections within sections, I have no way to map that back to 
>> MSXML.
>
>
> OK, but the "moreover" here is in not a metadata use case ;-)
>
>> If I had the metadate for these sections as having originated in 
>> MSXML, then my ODF application could restrict the use of sections so 
>> that I have a clean conversion back to MSXML.
>
>
> I was thinking based on our earlier conversations with Florian that it 
> would be helpful just to have some property-value flags to signal how 
> to handle certain behavior. I can see that easily in what I've been 
> envisioning.
>
> But adding a whole layer of complex xpath stuff to actually embed 
> conversion logic within ODF documents seems like a different matter.
>
>> That there are many ways to do conversion has no relevance to the 
>> question of whether this is "metadata" or not.
>
>
> Only in the sense that it's still not clear to me that this is within 
> scope of "metadata."
>
>> The question is whether structure (XML markup) is data in an XML 
>> document instance or is only the content within XML markup data.
>
>
> Thanks for this clarification. It's helpful.
>
>> I take the position that both markup and content are data in the 
>> sense that both can have metadata associated with them.
>
>
> I take a different view. The objects we are concerned with are the 
> objects that users deal with:
>
>     documents
>     figures
>     tables
>     citations
>
> ... and depending how granular we want to get sections, paragraphs, 
> spans.
>
> It is definitely not some XML node.
>
>> There is no loss in having a general mechanism that can address both.
>
>
> If there is no loss, then perhaps we can make sure the requirements 
> reflect that? I vote against including this requirement explicitly, or 
> perhaps rephrasing it if we can come to some more clear consensus.
>
> [...]
>
>> Note I was not suggesting that we *do* an interoperability mapping 
>> but provide a standard mechanism for anyone who wanted to do one.
>
>
> OK.
>
>>> I'm really not following the use case tie-back here Patrick.
>>>
>> The use case that was contribued by Florian if I am not mistaken 
>> raised the issue of conversion.
>
>
> Yes, but I was never really clear what he was saying (why I didn't 
> include it), and thought he recently clarified that it has a somewhat 
> different (more narrow) requirement.
>
> Bottom line on this one: I'm confused ;-)
>
> 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!