Re: [office-metadata] Rough Proposal for RDFa + RDF/XML/XForms +xml:id

[Patrick Durusau <patrick@durusau.net>]

Michael,

BTW, thanks for your post on the support of "unknown" content issue. 
That was very helpful, at least for me.

I look forward to hearing your explanation of your proposal as I don't 
think the choice of RDFa or RDF/XML + XForms is an either/or one.

Hope you are having a great day!

Patrick

Michael Brauer wrote:

> Hi,
>
> this rather long mail at its end contains a proposal for supporting meta
> data via RDF/XML+XForms, a subset of RDFa, and XML-Ids. Unfortunately,
> this proposal is not understandable without reading the longer
> introduction text:-(
>
> Svante Schubert wrote:
>
>> Hello Bruce,
>>
>> Bruce D'Arcus wrote:
>>
>>>
>>> On Feb 6, 2007, at 10:14 AM, Svante Schubert wrote:
>>>
>>>> As far as I know there was agreement to figure out these advantages 
>>>> by providing implementations for the examples Bernd has given 
>>>> http://wiki.oasis-open.org/office/ExampleDocument.
>>>> Do we still agree on that?
>>>
>>>
>>> I and Elias already provided tons of examples.
>>>
>>> <http://wiki.oasis-open.org/office/Metadata_Examples>
>>>
>>> I don't have time to do more. So if someone else wants to adapt them 
>>> to Benrd's page (through links or whatever) that's fine, but it's 
>>> not likely going to be me.
>>>
>>> I really don't think we have time for more discussion. Even if we 
>>> agree today that we need both the attribute and RDF/XML approach, we 
>>> still have a lot of work to do.
>>>
>> I agree that there is little time left. Believe me I try to focus 
>> with my questions on this list on the remaining problems.
>>
>> We might split the RDF metadata problematic into two general areas, 
>> which affect ODF
>>
>>   1. The subject is in the content
>>   2. The object is a literal and in the content.
>
>
> I agree to Svante regarding these two general cases, but would like to
> know if this a common understanding of the SC, or just Svante's and my
> understanding.
>
> The first use case is the case where a document contains some text, an
> image, a table cell, etc., and where the user wants to add additional
> information about this text (for instance an annotation, author
> information, whether it is important, and so on). It is also the use
> case where a document is converted from other document formats, and
> where additional information about the text, etc. that does not have a
> counterpart in ODF should be preserved.
>
> My understanding is that one possibility to store these metadata is
> - to add an id to an appropriate element that contains the text, table
> cell, etc., and
> - to use the either relative or absolute URI of the content.xml with the
> id attached as fragment identifier as subject in the RDF triples that
> are stored in a RDF-XML stream next to the content.xml.
>
> Is that correct?
>
> Bruce, am I right that this is exactly what you propose in your Image
> and Table examples?
>
> This first use case is actually the case where I think subjects may be
> splitted: The user may select some text regardless of paragraph or
> boundaries and the like, and may then attach author information to it.
>
> However, the only extension to the above we would need in this case is
> the possibility to identify these selection with a singe id. That's
> something we have to add at the ODF content level, not at the meta data
> level. There are many option how to do that. One is the start- and
> end-element solution we use for bookmarks already, that we may want to
> reuse in order to remain consistent with the remaining specification. 
> But that's an issue we may work on in detail if we agree that RDF-XML 
> + ids is the right solution for this use case.
>
>
> Regarding the 2nd use case: This is the use case where the literal
> object of an RDF triple is either in the content, or displayed there.
>
> The task to display such content is not new in ODF. ODF therefore
> already has concepts that we may use as basis.
>
> The first one are text fields. They display some text content, and
> contain a description where this text content comes from. On the XML
> level they are just XML elements, whose text content is the text to be
> displayed, and that have some attributes that specify what shall be
> displayed.
>
> We therefore could add a meta data field. There are two options for
> this: First we may add attributes for the RDF subject and predicates, 
> and may define that the text content of the field is the literal RDF 
> object. I think that is very similar to a subset RDFa, except that the 
> meta data attributes are not attached to arbitrary elements, but that 
> there is a specific element that carries the meta data attributes, and 
> that these elements cannot nested.
>
> The other option is to have the meta data in separate stream (including
> the literal object), and to have attributes that specify what RDF
> literal objects shall be displayed. This takes us directly to XForms,
> the 2nd feature that we may reuse, as Svante is pointing out: XForms can
> be used to bind controls and text fields (although we don't have the
> later right now) to RDF objects in an RDF-XML stream. This works 
> already in ODF 1.1 (but for controls only). It therefore seems to be 
> reasonable to reuse XForms for all those cases where the metadata
> is in a separate stream in the package, and where we want to display
> some of the RDF objects in the content.
>
> If we want to reuse existing concepts, we therefore have two options:
> 1. Some kind of RDFa-text-field as descibed above.
> 2. RDF/XML+XForms
>
> Actually, I think an RDFa based text field and RDF/XML + XForms
> supplement each other. The RDFa text field is a good choice if the data
> duplication of literal objects is a concern, or if there is no RDF/XML
> instance already existing. The XForms solution is a good choice if one
> already has an RDF/XML document that should be included, if the meta
> data is very complex, or if a strict separation between meta data and
> office content is requested.
>
> I therefore propose that we support both options, and additionally of
> cause what is required for the "subject is in the content" case.
>
> Best regards
>
> Michael
>
>
>
>

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!