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: {spam?} Re: [office-metadata] Re: {spam?} Re: [office-metadata] clarifying fields and metadata



On Mar 13, 2007, at 11:30 AM, Elias Torres wrote:

>> Tell you what: if Elias is fine with this, I won't protest. It's up to
>> him as far as I'm concerned.
>
> Wait a minute. I'm not agreeing to that....

Had a feeling you might say that :-)

> at least I have not followed
> this aspect too closely. At the end of the day a plugin can do what it
> wants and decide to use the meta:property to look up a display property
> when using a text:field but we shouldn't specify that. I think we need 
> to
> have a clear specification (no dual-purposes) of what do the attributes
> generate e.g. triples and let the implementors show us the rest once we
> have some real-world experience.

Agreed, though we're left with practical questions about how best to do 
this. We could move everything (or almost everything) to the RDF/XML, 
or we could keep some of it in the field and leave room in the RELAX NG 
for foreign-namespaced attributes.

> In Svante's example, he uses the property to explain what the text 
> value of
> the element means, the rest he's pushing to the RDF/XML. If you really 
> want
> to be specific about what does your triple mean take it to the RDF/XML 
> then
> would something like this work for you?
>
> <text:p xml:id="foo">bar</text:p>
>
> in RDF/XML
>
> <content.xml#foo> rdf:type cite:Citation ;
>       cite:displayProperty vCard:FamilyName .

If you're asking me, I don't care about the diplay-property thing. I am 
a little about moving what I take to be in-content, um, content, to the 
package (though am open to be convinced it's not a problem).

> I think that overloading too many meta:attributes on our first pass is 
> very
> dangerous. Let's meet the requirements of extraction, extensibility,
> naming, in-content metadata, etc. but not over do it.

Agreed. OTOH, there is well-known field behavior that we *could* use. 
They always involve one or more IDs and optional parameters.

In my OOXML example, and as I've been thinking about this since before 
OOXML existed, the field contains one or more IDs that reference the 
source data, which gets stored in the package. That reference is in 
fact intrinsic to the content in the same way that if you define a 
string in content as a dc:title it is intrinsic, so seems to me more 
sensible that it be stored with the field.

In fact, this idea is exactly why we had Svante suggesting stuff like:

<text:meta:field
	meta:about="http://ex.net/1";>foo</text:meta-field>

The critical URI anchor is there with the content.

For my use case, that doesn't work, though (because I can have multiple 
subject URIs), so I'm forced to use a different mechanism where 
everything is shifted to the package RDF/XML.

That inconsistency is what has me worried. While I could just use the 
dedicated citation field, it seems to me the generic metadata support 
should be able to support the use case.

Bruce



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]