Re: [office-metadata] Re: ODF and semantic web

Hi Mark,

Great to have your feedback on this. Bruce knows the concerns that  
drove this and gave a good summary. In my heart, I have to admit that  
I had a sweet spot for taking the route you propose. but I also  
recognized the cogency of the concerns Bruce and others brings/ 
brought up.

We're still at a "first official proposal spec" phase, of course. I  
wonder, if you and others from RDFa taskforce would make your  
presence known in ODF-metadata, whether it still might be something  
to think about to make straight RDFa an option, perhaps in the next  
proposal go-round. It's modularity makes it pretty easy to bring across.

The other point is we have mostly done demo documents using the out- 
of-content, more heavyweight model. I personally haven't authored any  
in-content documents (though Bruce will remember back at the very  
beginning of the process I was a strong proponent for an in-content  
option). It's always possible that when we get more prototype docs  
out there we'll find that pure RDFa has advantages we hadn't factored  
in.

I guess what I'm saying is that if you and your colleagues would  
weigh in on this in group discussions, those of us already in the  
group would enthusiastically welcome your input. We're a incredibly  
open and enthusiastic group, and all of us are committed to making  
this a killer spec.

On another topic, we've had a number of discussions--and I have  
authored a sample doc-- that use XForms to generate as output an RDF  
instance. This is using the out-of-content,heavyweight model. To me  
this is very exciting.

There are some constraints and issues -- the way I did it was to  
generate a prototype RDF instance which I made into an XForms model,  
and then "fill in the bits". But because, in point of fact, a given  
RDF graph can be serialized in many different ways, this need to  
commit to a single prototype serialization a priori is a little  
clunky.  It would be nice if XForms could address the underlying RDF  
graph, rather than one paricular serialization of it.

But XForms can't so this, because its path language is XPath, and  
XPath addresses xml, of course. On the other hand, if the XForms spec  
would allow a form to use, let's say, SPARQL as its path language,  
then the form could address the underlying RDF model instead of just  
a particular serialization of it.

Any chance XForms might eventually allow other path languages to  
address the model other than XPath for this reason?

John




John F. Madden, M.D., Ph.D.
Associate Professor
Department of Pathology (3712)
Duke University Medical Center
Durham, NC 27710
USA

john.madden@duke.edu
+1 919 681 6671 (voice)
+1 888 681 6671 (fax)
+1 919 597 0304 (mobile)
+1 800 307 9538 (pager)


On Oct 14, 2007, at 8:33 AM, Bruce D'Arcus wrote:

> Hi Mark,
>
> On 10/14/07, Mark Birbeck <mark.birbeck@formsplayer.com> wrote:
>
> ...
>
>> I note that the attributes used in ODF are 'inspired' by RDFa [1]-- 
>> but
>> why not just incorporate RDFa as is?
>>
>> It's especailly confusing for authors when this 'inpiration' seems to
>> involve copying some RDFa attributes, but changing the names of
>> others. For example, @about is used, but @datatype has been  
>> renamed to
>> @data-type!
>
> The explanation of why we didn't use RDFa as is goes back to what I'd
> call the unique challenges of integrating RDF into an already deployed
> XML format for productivity applications.
>
> A few issues off the top of my head :
>
> * all nodes in ODF must be namespaced; the RDFa attributes are not
>
> * uneasiness about CURRIEs in attributes (we require the full URI)
>
> * the big one: using the short-hand syntax in the context of an
> editing application. ODF is rarely going to be hand-authored, and
> implementors thought it too large a burden to be responsible for
> tracking the subject URI apart from the rest of the triple in the
> context of a dynamic content environment, where users are going all
> kinds of funky things. So, for example, we require the subject and
> predicate URI to be on the same node.
>
> I don't recall the datatype vs. data-type issue, but it is probably a
> consequence of consistency with existing ODF patterns. I can check on
> that, as the details are not set in stone.
>
>> This lack of alignment is a shame, especially when the proponents of
>> ODF are generally critical of the confusion that can be caused by
>> companies and organisations pursuing alternate document formats.  
>> There
>> is a fantastic opportunity here for creating tools and search engines
>> that could leverage a 'standard' way of incorporating metadata into
>> HTML, XHTML, ODF, and other mark-up languages. That opportunity now
>> looks like it is going to be missed.
>
> That's too strong, and is only the case if you believe RDFa is the
> only way to integrate metadata into content.
>
> The in-content ODF metadata syntax is a subset of RDFa; one can easily
> write an XSLT that maps it perfectly to RDFa (or RDF/XML, TriX, etc.).
>
> I think the expectation is that the most common case will have the
> triples serialized as RDF/XML in the file package.  For example, my
> focus is citations. In that case, we'll have a simple field with the
> formatted text, but the citation metadata will get stored as RDF/XML.
> Once one gets into more complicated metadata scenarios, this would
> seem the preferable approach.
>
> We've adopted a kind of minimal syntax for in content statements where
> the object is a literal. I can imagine in the future this subset might
> be expanded as implementors gain experience.
>
> So I guess recognizing the above, are there any changes you think are
> important for us to consider now?
>
> Bruce