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,

Bruce D'Arcus wrote:
> This is a bit of a followup to the question about in content resource 
> references from the other day. Let me summarize where I think we're at 
> with the current proposal draft:
> 
> We have basically ways to tie content to metadata.
> 
> 1) RDFa-like attributes, but which are constrained to represent 
> literals. The purpose here it o create RDF statements out of content in 
> the document. Example:
> 
>     <text:p
>         meta:about="http://ex.net/1";
>         meta:property="http://ex.net/foo";>bar</text:p>
> 
> This would generate the triple:
> 
>     <http://ex.net/1> <http://ex.net/foo> "bar" .
> 
> I think we've all gotten comfortable enough that there are circumstances 
> where this will be valuable.

As for me: yes.
> 
> 2) A new field (currently called meta:label) whose purpose is only to 
> attach statements to content. This is really just a field tied to 
> RDF/XML data, where the content of the element is generated from that 
> data, and serves as a label. But there are no formal semantics 
> associated with it. The attributes are a little unclear to me still, but 
> think something like:
> 
>     <meta:label meta:about="http://ex.net/1";>Jane Doe</meta:label>

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.
2. One or more attributes (or some other mechanism) that allows the 
office application to efficiently select the right component that 
maintains the label.

And as mentioned already some time ago: The field really should be from 
the text namespace.

> 
> 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.
> 
> Bruce
> 

I hope that helps.

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]