Re: [office-metadata] RDF/XML and XPath

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Bruce,

Bruce D'Arcus wrote:
> Hi John,
> 
> On Feb 11, 2007, at 5:56 AM, John C Barstow wrote:
> 
>> I'm going to raise my head above water here to mention that the XPath
>> problem is *precisely* why the TriX format[1] was invented.
> 
> But it's not standardized, so I think is a no go. Also, Dave Beckett -- 
> who updated the 2004 RDF/XML spec and also wrote an alternative RDF XML 
> syntax similar to TRiX -- has not come to such clear-cut conclusions on 
> syntax.

Well, if we store meta data based on something that is not standardized, 
then we have to copy the specification. Regardless whether this is 
possible, this would be a lot of work, and may be also a contradiction 
to our charter, that says we "should 'borrow' from similar, existing 
standards wherever possible and permitted". So, I don't doubt that there 
are alternatives to RDF-XML that solve a lot of problems that RDF-XML 
actually has, but I'm not sure whether we can use them unless they are 
standardized.

However, it is of cause a valid option to restrict the RDF-XML, so that 
we can locate certain triples using certain XPath expressions, or get 
more friendly to XSLT. Actually, we are in the position where we can do 
so, because our requirement is to store metadata in an appropriate way 
only, but not to support RDF-XML itself.

> 
>> One of the core requirements was that the format be amenable to
>> processing with XPath and XSLT, one which I think it meets admirably
>> (incidentally supporting one of my pet features, named graphs).
> 
> I think if we recommend basic conventions (such as properties should be 
> represented as elements) it will be friendly-enough to XSLT. It will 
> certainly be much, MUCH friendlier than any arbitrary XML is, and so a 
> big improvement on the current state of things.

I'm wondering if we have a dis-agreement at all? If we make these basic 
convention that makes the RDF-XML instance friendly to XSLT, doesn't it 
make the same instance friendly to XForms, too? But see below.

> 
> I have already demonstrated a generic XSLT to convert all statements in 
> a package to HTML.
> 
>> Bruce may be unaware of this, but one of the reasons RDF stumbled so
>> badly when first introduced was the RDF/XML syntax.
> 
> I am, but I just don't agree with your analysis [1]. I think one major 
> failing of how RDF has been implemented is that people confuse syntax 
> and model.
> 
> But the more important issue that the specific problem here is not 
> really syntax; it is display binding. Do we *require* using XPath (which 
> depends on syntax) to do that, or use a mechanism more appropriate to 
> the RDF model (and so independent of syntax)?
> 
> *That* is the question.

I agree. The display binding, or more generally, a binding between meta 
data related information in the content and an RDF-XML instance, is the 
question we are discussing, and it is my impression the only item where 
we did not reach a consensus so far.

In theory, we don't need such a binding. We can create the RDF graph, 
and can operate on it. That's true.

A RDF application that reads the meta data in order to get the semantics 
of a document does not need such a binding as well. It simply creates 
the RDF graph.

But consider a plug-in for an office application that is specialized to 
let's say vCard entries: How does it know where the vCard entry is 
stored if it wants to provide the user the option to update it, or to 
choose an alternative predicate. How can it update its own data (and 
only its own data) if it operates on the RDF graph that may have been 
constructed from multiple RDF-XML, and therefore does provide the 
information where the data is stored physically? How can you save the 
plug-in from processing the data of other plug-ins (for instance a 
bibliography plug-in).

These are in fact practical or implementation questions, and we can 
leave this open in the specification. However this may make the 
implementation of such plug-ins complicated, and may cause conflicting 
implementations.

Or we define bindings, which indeed have to contain some information 
about the physical representation of the meta data if they shall provide 
a solution for the above practical issues. Using XForms bindings is an 
option we should consider, because we have it already in the 
specification, but it is of cause not the only option. If we find other 
ways to define bindings that are either standardized, or are simple to 
specify and implement, and that do not duplicate XForms bindings, then 
this is fine for me, too.

Some general remarks that may help us to define such bindings:

- Application that are only interested in getting the semantic of a 
document don't need have to consider it. That's worth mentioning, 
because we are adding the meta data so that other application can read 
it, and it is important to understand that exactly these application 
don't have to care about the bindings.
- If we support multiple RDF-XML streams (and I think that's the current 
consensus), then an application may add new meta data without caring 
about bindings, by adding them to a new stream.
- The only applications that have to care about the bindings are those 
that want to update metadata that is referenced in the content.
- To be able to specify bindings, restrictions can be made for the 
RDF-XML, but also for the bindings themselves (for XForms bindings, we 
could for instance make strong restrictions regarding the XPath 
expressions, too).
- A binding that has only minimal dependencies from the phyisical 
representation is to use Ids.

I hope this helps.

Michael