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] Export / Import of metadata



Bruce D'Arcus wrote:
>
> On Feb 28, 2007, at 12:58 PM, Svante Schubert wrote:
>
>> We have the requirement:
>> "Metadata must be able to be processed, extracted, removed and so 
>> forth independently of the document content."
>
> Since I wrote that, I really meant "where the metadata is in fact 
> independent of the content."
>
>> How do we fulfill the requirement of to extract/export metadata 
>> (which might be done using RDF/XML), when we have to differentiate 
>> the following use cases for RDFa:
>>
>>   1. RDFa refers to the literal from the concatenated text nodes
>>   2. RDFa refers the XML subtree, which seems the default from RDF/XML
>>      sight using 'XMLLiteral'
>>   3. RDFa just gives information about the element it resides on - is
>>      this a use case for RDFa?
>
> As an example, it's really trivial to write an XSLT to convert all in 
> content statements to RDF/XML. That XSLT could just have a rule like:
>
>     - if there is an explicit data-type attribute that indicates plain 
> text, then strip the nodes from the content and output
>     - else transform to literal with XMLLiteral data-typing.
>
>> This becomes important during export of the metadata. In my example 
>> above the whole text of the introduction would be exported as 
>> metadata literal, which was not my intention. As I see the text of 
>> the introduction as the content not as metadata. All I intended to 
>> export is the RDF statement classifying the paragraph, for example by 
>> xml:id.
>>
>> Would it appropriate to assume that RDFa always refers to the literal 
>> of all concatenated text nodes (case 1) , we do not support the XML 
>> subtree for now (case 2) and by xml:id reference we handle the 
>> element itself (case 3)? This would solve my problem above.
>>
>
> My answer: as above, we assume XML literal unless there's a data-type 
> that says otherwise, and treat accordingly.
>
> Simple enough.
Not simple enough to copy & paste your answer to the proposal.

I have read again the chapter about XMLLiteral in the spec
http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral
and I now would think my earlier cases 1 & 2 are identical. The 
XMLLiteral is resolved to a string, is this correct?

Therefore do we agree on that RDFa is always using the concatenated 
descending text nodes of the RDFa element as RDF object?

- Svante







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