[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] Rough Proposal for RDFa + RDF/XML/XForms + xml:id
On Feb 7, 2007, at 10:35 AM, Michael Brauer wrote: >> 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. I guess, but I'd maybe just want to say for 1 "one wants to make statements about arbitrary content in the document". > 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? Yes. > Bruce, am I right that this is exactly what you propose in your Image > and Table examples? Yes, though the wiki examples there do not reflect the more recent discussion of absolute vs. relative, global vs. local URIs. For the case Svante presented, using a global absolute URI may be important. > 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. Yes, but it's not the subject that gets split. The subject is just a URI. It's the object literal of a property of that subject. > 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. Right. > 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. OK, that might be fine. It at least includes the attributes. > 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. I haven't had a lot of time to think about this, but it seems reasonable. But XForms is just one way to bind a GUI to the RDF content (an implementation detail); is it really something we have to worry about at the ODF level? Bruce
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]