[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]