[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] clarifying fields and metadata
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. 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. >> 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? Bruce
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]