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: Re: [office-metadata] Suggestion for next version of ODF-OWL


Hi guys,

Just to follow up on my Note (d) from the previous email, I want to show you two versions of an example manifest.rdf file. One uses the odf:idref mechanism to identify an element in a content file, the other uses a "native xml" syntax for locating resources in files, the way I think XSCD approaches the issue. That one just takes the urn:uuid of the ODF package as the namesapce prefix for the document, appends the file path usiing the usual "/" syntax, and then adds the xml:id after a "#".

Let me know how you all feel about this.

It's interesting to note that the groups discussing how to deal with user-specified types in RDF has a spookily similar discussion a couple of years ago.  One group working with Protege-OWL (the Manchester folks) who had an experimental rdf-property based proposal (http://protege.stanford.edu/plugins/owl/xsp.html) where they defined some new properties to refer to the items being targeted in the XML Schema file. Another group (the W3C authors of the already-referenced http://www.w3.org/TR/swbp-xsch-datatypes/) suggested a solution that looks like the second one here.

Anyway, enjoy...

Option (1): use specially-defined properties to reference the foreign id's:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rdf:RDF [
<!ENTITY uuid "urn:uuid:" >
]>

      <owl:Ontology rdf:about="">
            <owl:imports rdf:resource="http://docs.oasis-open.org/opendocument/meta/package/common"/>
      </owl:Ontology>
      <common:Package rdf:about="&uuid;a4bcb5e0-5ce1-11dc-a5f7-0002a5d5c51b">
            <common:hasPart rdf:ID="this_Content">
                  <odf:ContentFile rdf:ID="this_Content">
                        <common:path rdf:datatype="&xsd;anyURI">content.xml</common:path>
                        <common:hasPart>
                              <odf:Element rdf:ID="this_Patient">
                                    <common:idref rdf:datatype="&xsd;NCName">this_patient</common:idref>
                                    <!-- actually, I think a path specification on an element which is already known to be part of content.xml because of the enclosing element is redundant, but I'll include it here anyway -->
                                    <common:path rdf:datatype="&xsd;anyURI">content.xml</common:path>
                                    <!-- end (in my opinion) redundant assertion -->
                              </odf:Element>
                        </common:hasPart>
                  </odf:ContentFile>
            </common:hasPart>
      </common:Package>
</rdf:RDF>


Option (2): use "nativist" approach

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rdf:RDF [
<!ENTITY uuid "urn:uuid:" >
<!ENTITY pkg "&uuid;a4bcb5e0-5ce1-11dc-a5f7-0002a5d5c51b" >
]>

      <owl:Ontology rdf:about="&pkg;">
            <owl:imports rdf:resource="http://docs.oasis-open.org/opendocument/meta/package/common"/>
      </owl:Ontology>
      <common:Package rdf:about="&pkg;">
            <common:hasPart rdf:ID="this_Content">
                  <odf:ContentFile rdf:about="&pkg;/content.xml">
                        <common:hasPart>
                              <odf:Element rdf:about="&pkg;/content.xml#this_patient"/>
                        </common:hasPart>
                  </odf:ContentFile>
            </common:hasPart>
      </common:Package>
</rdf:RDF>



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