Re: [office-metadata] Focus on model

[Elias Torres <eliast@us.ibm.com>]

Lars.Oppermann@Sun.COM wrote on 12/14/2006 09:39:50 AM:

> Florian, and all the others...
>
> I did not follow the recent discussion in all its detail, please let me
> know if I'm going into the wrong direction here.

Not at all. You seem to have a good grasp on the subject.

>
>  From what I have read during the last days, I was of the impression,
> that marking fragments of OD content as subjects about which metadata
> statements are made is a well agreed upon concept. I got the impression
> that most of the problems were in cases, where OD content should be used
> as the object of such a statement.
>
> Consider the statement
>
> {the_fragment-called_A; was_authored_by"; "John Smith"}
> {the_fragment-called_A; was_authored_by"; "John Smith"}
>
> Assuming document content like this
>
> <t:span xml:id="A">blah blah blah</t:span>
>
> This could be encoded in an RDF/XML-like fashion as already noted like
this:
>
> <rdf:RDF>
>    <rdf:Description rdf:about="#A">
>      <dc:author>John Smith</dc:author>
>    </rdf:Description>
> </rdf:RDF>

Absolutely correct.

>
>  From what I understood from the ongoing discussion, it is not yet clear
> how this can be done, if the "resource" 'Jonh Smith' is to appear as
> part of the document content, so as to avoid any redundancy. Consider we
> have content as this:
>
> <t:span xml:id="A">blah blah blah</t:span>
> <t:span xml:id="B">John Smith</t:span>
> <t:span xml:id="C">14 December 2006</t:span>
>
> We can reformulate the previous RDF/XML example to read as follows:
>
> <rdf:RDF>
>    <rdf:Description rdf:about="#A">
>      <dc:author rdf:resource="#B">
>      <dc:date rdf:resource="#C">
>    </rdf:Description>
> </rdf:RDF>
>
> What use-cases can't be implemented by this simplistic approach? Why is
> there a need to introduce anything beyond a mechanism for referring to
> fragments into the content?

This is exactly what I detailed in a previous email. The problems are:

- We are stepping outside of RDF standard processing and assuming that the
person knows that #B is not a real resource but in fact a special type of
resource called OD element that needs to be de-reference and it's content
turned into a literal.
- We lose the ability for the RDF to be processed stand-alone by other RDF
tools.
- If you look at the example below, you don't have a way to differentiate
from RDF "resources" from OD resources
- Not all ontologies allow us to substitute literals with resources
- We lose some copy and pasteability because it's not a trivial process to
extract a subset of the graph from the meta(s).xml files.

<rdf:RDF>
   <rdf:Description rdf:about="#A">
     <dc:author rdf:resource="#B">
     <dc:date rdf:resource="#C">
    </rdf:Description>
   <rdf:Description rdf:id="#C">
     <rdf:type rdf:resource="#SomethingElse">
    </rdf:Description>
</rdf:RDF>

-Elias

>
> Thanks,
> Lars
>
>
> Florian Reuter wrote:
> > Dear collegues,
> >
> > may I suggest a way to approach consensus in our discussion. To me
> we mix the encoding problem (RDFa, IDs, Styles) with
> > the problem of the underlying metadata statements we would like to
allow.
> >
> > I would suggest to first try to get a consensus about which
> statements we would like to allow and then talk about the
> > way we would like to encode them in OD.
> >
> > The first question is whether we can get an agreement which kind
> of statement we would like to allow and at the very
> > beginning whether this should be RDF (subject, predicate, object)
> statements or something different.
> >
> > If we agree on RDF triples as the underlying model, then I guess
> we need to talk about what special OD items we would
> > like to allow beeing a "suject". E.g. candidates would be
> "paragraphs", "spans", etc.
> >
> > If we agree on this and our use cases can be solved using the
> underlying metadata model we have in mind, then we can
> > talk about how we can encode then in OD either by using an RDFa
> like approcach, a style-based approach or an ID-based
> > approach.
> >
> > Does this makes sense or am I off thead?
> >
> > ~Florian
> >
>
>
> --
> Lars Oppermann <lars.oppermann@sun.com>               Sun Microsystems
> Software Engineer                                         Nagelsweg 55
> Phone: +49 40 23646 959                         20097 Hamburg, Germany
> Fax:   +49 40 23646 550                  http://www.sun.com/staroffice