Re: [office-metadata] Some implementation drafts aside of RDFa

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

On Dec 12, 2006, at 5:27 PM, Svante Schubert wrote:

>> I think you're confusing the issues here. I'd prefer to talk about 
>> the model (the RDF triples) and how to bind statements to content 
>> nodes.
>>
> But don't you see, the xml:id is a very simply way to be able to 
> identify a content, to which metadata will be related to.

The problem is the model: you are not defining what *kind* of content. 
An xml:id attribute identifies a resource; not a property. And we need 
to distinguish them.

> A big advantage against RDFa is that it not require an additional set 
> of new attributes to be introduced to ODF only one 'xml:id'. Even more 
> it is already a requirement from different side. Can it be simpler, 
> more elegant?

I think we can do without rel and rev. The important ones are about, 
property, content and what I am going to call "resource". That's four 
attributes.

Attributes in any case are painless to add from an XML standpoint; no?

> But only if xml:id="table-1" is your desired subject, not if you are 
> looking for a set of structures, which in total represent your 
> subject, like the example of the user marking a group of elements. Or 
> a couple of text passages you mark as important.

Use meta:about or meta:property instead. E.g. I think there's ways to 
address this.

...

>>> Question: How is validation being added? If I want to ask if for 
>>> example to document being an invitation has the required data and 
>>> location?
>>
>> I see different options if you need to do datatyping.
>>
>> 1) you add a datatype attribute to the content node directly
> Do you like to introduce a new datatype nodeset for ODF and even if we 
> had such, what about restriction among given datatypes, like 
> Schematron might validate?
> Furthermore, schema vary a lot RelaxNG, W3C Schema, etc.. Don't you 
> think, that by separating these things from the content, which can be 
> changed separately from the content, we become more flexible?

I'm not committed this; just saying it might be one way.

>> 2) you include it in the package
> Yes or we provide a reference when the information resides outside the 
> package
> But how do you connect these schema information with content & 
> metadata? Why not taking ideas - as the introduced bindings - from 
> XForms, which is already W3C standard?

We are relying on a W3C standard here: RDF.

This is why I keep saying: think about the model. If I have this:

<owl:DatatypeProperty rdf:about="http://ex.net/event#date";>
   <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/>
   <rdfs:label xml:lang="en">date</rdfs:label>
</owl:DatatypeProperty>

... it can be represented in N3 as:

<http://ex.net/event#date> a owl:DatetypeProperty ;
     rdfs:range <http://www.w3.org/2001/XMLSchema#date> ;
     rdfs:label "date"@en .

OK, keep in mind the triples (three of them), and keep in mind the URI 
there.

Now, you assign a property to a node using the same URI.

<text:span 
meta:property="http://www.w3.org/2001/XMLSchema#date";>...</text:span>

So what's the problem? You are in fact in that process associated a 
statement about the datatype to that content node.

The groups at the W3C are charged with integrating their efforts. This 
is why, of course, XForms builds off of XSD. Likewise, RDF also 
incorporates aspects of other specs, including the work on data-typing 
in XSD.

Let's use that work rather than invent non-standard mechanisms to 
achieve the same thing?

> Looks fine for common datatypes, but what about validating that my 
> invitation meta data in the content, which has to have a date and 
> location?

You can use a standard cardinality property from OWL if you like:

<owl:DatatypeProperty rdf:about="http://ex.net/event#date";>
   <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/>
   <rdfs:label xml:lang="en">date</rdfs:label>
   <owl:cardinality>1</owl:cardinality>
</owl:DatatypeProperty>

Am just trying to emphasize there are a variety of ways to achieve this.

I imagine you could also use XForms as well; maybe even converting the 
output (using XSLT) to the RDF if you want.

Bruce