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] clarifying fields and metadata


Bruce D'Arcus wrote:
> 
> On Mar 13, 2007, at 2:59 AM, Michael Brauer - Sun Germany - ham02 - 
> Hamburg wrote:
> 
>> In general, yes, but I think two things are missing here:
>> 1. One or more attributes that further describe how the label is 
>> composed, so that you can actually get different labels for the same 
>> subject (for instance the first name and the family name separately). 
>> These attributes actually would not have any meaning for the RDF data, 
>> and also not for the office application, but only for the component that
>> maintains the label. It could be for instance a "text:label" attribute 
>> that takes an IRI. I could also imagine to call it "text:property" (or 
>> meta:property). The component than could check if the attribute 
>> describes a valid property, and if so, display that. And if is not a 
>> valid property, then it could interpret the value as some kind of 
>> "virtual" property that shall be displayed.
> 
> This would be optional, yes? I could imagine it wouldn't be needed in 
> many cases.

That's okay for me.

> 
> In any case, I would discourage reusing meta:property in that circumstance.
> 
>> 2. One or more attributes (or some other mechanism) that allows the 
>> office application to efficiently select the right component that 
>> maintains the label.
> 
> Right.
> 
>> And as mentioned already some time ago: The field really should be 
>> from the text namespace.
> 
> Yes, I think meta:label should in fact be text:field.

text:field is very limited. What about text:meta-label?
> 
>>> But we're missing something which is really a sort of hybrid 
>>> situation: in content metadata which may be field-like. From one of 
>>> our (medical) use cases:
>>>     <meta:label
>>>         meta:about="http://ex.net/contacts/1";
>>>         meta:property="http://medical.org/patient";
>>>         meta:resource="http://ex.net/contacts/2";>Jane Doe</meta:label>
>>> This would generate a triple of course:
>>>         <http://ex.net/contacts/1> <http://medical.org/patient> 
>>> <http://ex.net/contacts/2> .
>>> So my question is really how we define #2 formally in ODF?
>>
>> Why not in the way your example suggest? The attributes describe the 
>> triple, but the content of the field is just a label. Well, because of 
>> the different semantics, you may want to call the field differently.
> 
> I just mean, how do we define this field in the RELAX NG such that both 
> use cases are supported? Or do we agree we need both?

Well, if the two fields have different attributes and a slightly 
different meaning, then it is probably best to have both.

Michael

-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


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