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: RDF representation of text:meta-field


Bruce,

 you currently asked to add an RDF representation of the text:meta-field 
to be able to describe the prefix and suffix of it's content in RDF.
Are there further properties you have already in mind for the 
text:meta-field?

As Patrick is with you and no one else objected, I believe the SC could 
agree on base functionalities.

Michael suggested that regarding your prefix/suffix request it might 
even be possible to reuse existing ODF functionality (Chapter 14.7 "Data 
Styles" in the predraft 4 latest).
Instead of reinventing local dependent date / number formatting, we 
could reuse the date formatting provided from the ODF application.

To archieve this we would have to add the style:data-style-name 
attribute, which is already attached to multiple other fields, to our 
text:meta-field.
The data style supports prefix and suffix functionality. Even if this 
does not satisfy your scenario, we could at least base our ideas on.

Svante

Patrick Durusau wrote:
> Svante,
>
> On the whole I am with Bruce on this one. I don't think specifying a 
> bit more of the base ontology in any way impairs what people may 
> choose to do on their own and it does provide a common infrastructure 
> upon which they can build if they so choose. We are about 'standards' 
> after all although it isn't always clear where one wants to draw the 
> line in terms of standardizing today knowing that we will learn more 
> tomorrow.
>
> But learning more tomorrow about what we should have said today is too 
> commonplace to delay adopting what appears to me to be a very good 
> suggestion from Bruce. His suggestion does not limit us in any 
> significant way and provides a degree of uniformity for those who want 
> to run with our work in its present form.
>
> Hope you are having a great day!
>
> Patrick
>
>
>
> Svante Schubert wrote:
>> I would like to know how others from the Metadata SC think about this.
>>
>> Svante
>>
>> Bruce D'Arcus wrote:
>>> Svante Schubert wrote:
>>>
>>> ...
>>>
>>>>> We know -- by only looking at the RDF -- that foo:Bar is a kind of 
>>>>> field. This is not "syntactic sugar"; it's formal definition.
>>>> We might name the type similar to the ODF element, why inventing 
>>>> new names?
>>>
>>> That's unimportant to me. There might be some awkwardness in doing 
>>> so practically, though. We already invented odf:Element so I don't 
>>> see the issue with another new class or two.
>>>
>>>>> We can then also say that prefix and suffix for the field is common, 
>>>> Do we know that prefix and suffix will be used for all 
>>>> text:meta-fields or is it just one possible way to represent the 
>>>> format of a text field when used with citation - one possible 
>>>> implementation.
>>>> I wonder what the others saying about this, to me prefix / suffix 
>>>> is part of the user RDF/XML supposed to be handled by an extension 
>>>> not an Office.
>>>
>>> You're thinking like an office suite developer. For one thing, you 
>>> don't know that an office implementation won't be processing this. 
>>> Your assumption that it will all be left to "an extension" is thus 
>>> just that: an assumption without basis.
>>>
>>> It seems highly likely to me, in fact, that an editor might well 
>>> handle interpreting certain core properties and classes for 
>>> rendering. Prefix and suffix are in fact a perfect example of that.
>>>
>>> Moreover, even if this is handled in extension code, it's still 
>>> valuable to use common means to represent common concepts. A field 
>>> has a set of very basic concepts that are general: prefix, suffix, 
>>> target object, etc.
>>
>>>> The metadata SC could suggest how to solve such common problems, 
>>>> but as the metadata is used by an extension I see no reason to 
>>>> restrict this in the ODF spec.
>>>
>>> Again, you're making implementation assumptions that I don't think 
>>> are reasonable.
>>>
>>>>> and we can do this:
>>>>>
>>>>> field:prefix a owl:DatatypeProperty ;
>>>>>     rdfs:domain odf:Field .
>>>>>
>>>>> So inference can also realize that anytime someone is using a 
>>>>> field:prefix property, it is with reference to a resource of type 
>>>>> odf:Field (in addition to any other type, like foo:Bar). An RDF 
>>>>> library that supports inferencing can actually generate that 
>>>>> triple so that, for example, if you search for all resources of 
>>>>> type odf:Field, you also get all that use field:prefix, *even if 
>>>>> they are untyped* in the RDF/XML.
>>>> If you can figure out that field prefixes are being found in the 
>>>> RDF/XML by various metadata extensions, what advantage are you 
>>>> taking of it?
>>>> It seemed more reasonable to collect all prefix/suffixes of one 
>>>> domain, e.g. for citations.
>>>
>>> As above, what if the editing application -- not the extension -- is 
>>> responsible for that rendering. And what if every different field 
>>> uses different properties to represent the same thing?
>>>
>>> If you want, I can submit a full proposal for the citation stuff. 
>>> I'm trying not to do that because I'm busy and I don't think it 
>>> should be critical with some baseline stuff, but you're putting me 
>>> in an awkward situation.
>>>
>>> Bruce
>>>
>>
>>
>

-- 
Sun Microsystems GmbH           Svante Schubert
Nagelsweg 55                    Software Engineer
20097 Hamburg                   StarOffice / OpenOffice.org Development
Germany                         Phone: +49(0)40 236 46 500
http://www.sun.com              Svante.Schubert@sun.com

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



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