Re: [office-metadata] RDFa model and xml:id

[Svante Schubert <Svante.Schubert@Sun.COM>]

Bruce D'Arcus wrote:
>
> On Dec 13, 2006, at 3:57 PM, Elias Torres wrote:
>
> ...
>
>> I see a tangible benefit and that is content-duplication. We tried
>> explaining this on the call, but I guess we didn't make progress on 
>> that.
>> Let me repeat this again. RDF by nature deals very well with specifying
>> metadata externally from the content, so technically I can't argue 
>> with an
>> external only approach. However, content-duplication is something very
>> important ...
>
> I'm not sure that's the only issue.
>
> There may also be problems from an API and processing perspective with 
> the non-standard mechanism of associating properties with content nodes?
>
> E.g. this ...
>
> <metadata xml:id="m_001>
>   <property="snomed:birthdate"/>
> </metadata>
>
> ... *might* be possible to be made valid RDF, but I don't think it's 
> so straight-forward. So then we have the same metadata files with 
> standard RDF/XML and non-standard ODF RDF/XML, with little clear 
> benefit for anyone.*
>
> I'll defer to Elias to explain if and why my hunch here is right (or 
> not).
>
>

Let me summarize:
You think there might be an issue for the xml:id approach as you think 
it might be not be possible to map to RDF (without giving a example).
Further you think it is not straight-forward (without giving a example).

How can we compare the approaches in a more scientific manner?
>
> * I'm actually more comfortable with using the style redirection that 
> Florian likes to indicate properties than the xml:id approach for this 
> very reason (keep the package RDF files standard and clean). But that 
> would still involve a meta:property and/or meta:class attribute on the 
> style definition, in which case it's effectively XML window dressing.
>
Do we all agree on the saying that good design is a modular design?
If there are two parts like style and semantic, which sometimes might go 
together - as when a content of a certain semantic is formatted by a 
certain style - but usually are handled separately, a modular design 
would not interleave them, but handle them separately to avoid 
unnecessary dependencies.


Have a nice day,
Svante