[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]