OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Suggestion for next version of ODF-OWL


Hi,

I feel bad making these suggestions late in the game, and I would be delighted to consider these suggestions for the NEXT version of the spec.

Anyway, here is a suggested modification of the OWL schema. I've done several things here.

odf-meta-modified-stable.owl

(1) ContentFile, MetadataFile and StylesFile are now all children (rdfs:subClassOf) of File.

(2) I've added the obvious (to me) disjointness axioms. Package, File and Element are all mutually disjoint. ContentFile, MetadataFile and StylesFile are all mutually disjoint.

(3) I've added ranges and domains to the properties. 

--- for hasPart, the domain is Package, File or Element, range is File or Element;
--- for path, the domain is File or Element, range is rdf:Literal^^xsd:anyURI (see note (a) and note (d))
--- for idref, the domain is Element, range is rdf:Literal^^xsd:NCName (see note (b) and note (d))
--- for mimeType, domain is File or Element, range is rdf:Literal^^xsd:string (see note (c))

Note (a): We want odf:path to take either a relative or an absolute path. I *think* that xsd:anyURI will accept relative paths to local resources. If anybody knows different, let me know. Also see note (d) below.

Note (b): odf:odref obviiously can't take a type of xsd:idref or xsd:id, because it's in  a different document from the id it's referring to. In terms of their form, if I read the XML Schema spec properly, xsd:id is an xsd:NCName *after "resolution"*, that is an XMLS parser is supposed to remove whitespace before checking a document's idref or an id for referential integrity. By putting NCName here, I've required the author of the manifest.rdf to take out the whitespace manually, in other words, the use of xsd:NCName here would cause a parser to fail certain (whitespace-containing) strings that would pass muster if used as an idref or id in the target document.

Note (c): IMIME type/subtype name strings have the pattern  <pattern value="[A-Za-z0-9!#\$&\.\+-\^_]/[A-Za-z0-9!#\$&\.\+-\^_]"/> (Again, please check me on this, but I believe this XMLS regex is correct.) We *could* add a pattern restriction here of,, however, the way to add facets to xsd:simpleTypes within an rdf document don't have a completely implementation standard yet, (see http://www.w3.org/TR/swbp-xsch-datatypes/ . Therefore, I am just letting them use the rdf:Literal^^xsd:string type here. We can constrain later if we like.

Note (d):The use of odf:path/odf:idref is the most novel thing in this whole schema, in my opinion. It's an example of an rdf document referring into a generic xml document, and that's not been done terribly often. I think it's illuminating to look at http://www.w3.org/TR/swbp-xsch-datatypes/ (I also refer to this doc in Note (c)) because there the W3C rdf group has addressed the issue of referring into a separate XML Schema document from an RDF document -- a somewhat related situation. Their recommendation suggests using the XSCD (http://www.w3.org/TR/2005/WD-xmlschema-ref-20050329/) approach. What this means (again, if I read correctly) is that it would be universally understood that a urn of the form <document-base-uri>#<id> would refer to the desired element in the (in their case) XML Schema, with no further ado. If we were to adopt this approach, then it is possible that the odf:path/odf:idref properties would be supefluous (not wrong, but just not necessary, given the stated convention). I think we ought to talk with the editors of these two W3C documents at some point and discuss the relative merits of these various approaches. I'm quite happy with what we have for now.

John



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]