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: Rough Proposal for RDFa + RDF/XML/XForms + xml:id


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



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