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

[John@smtp.duke.edu, F.Madden@smtp.duke.edu, MD@smtp.duke.edu,PhD <john.madden@duke.edu>]

Mark--

The point being, I forgot to mention, that ODF uses XForms as its forms model -- which I'm sure you already knew.

John

On Oct 14, 2007, at 11:52 AM, John F. Madden, MD, PhD wrote:

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