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

[Bruce D'Arcus <bdarcus@gmail.com>]

On Feb 12, 2007, at 7:19 AM, Michael Brauer - Sun Germany - ham02 - 
Hamburg wrote:

>> 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.

It's a question of "should" vs. "must" language.

>> 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.

Correct. That's one end; the "it's not our problem" position.

> 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).

I agree we should define a mechanism to do at least some of this, and 
it seems to me the manifest is one obvious place. We allow metadata 
(and other files) to be typed or otherwise classified such that a 
plug-in would know which graph to use.

One could then always include a configuration file along with those 
graphs if necessary.

> 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.

My proposed solution above is not about the physical representation. We 
can say that each metadata file represents its own graph (from a model 
perspective).

> 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.

OK.

> 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.

Yes, but to bring this all back to the use case, being strict about 
bindings in the way you are meaning it would be really bad practice for 
my use case. All that's important is the URIs, and the generation of 
the presentation really should not be our concern.

I suspect there will be a *lot* of use cases like that. A simple 
convention for display-able data like "one may use rdf:value as a 
default display property for resources" would go a long way, and is 
simple.

Bruce