I'm eager to study these in detail. In the case of the XML-Schema representations, which I want to try to incorporate in several schemas, the import Schema Locations are relative and so it would be very helpful to have some kind of access to the actual schemas used in the imports. The most robust might be public read access to the SVN server holding these schemas.
Bob
Hi Bob,
I presume you are referring to the work I am doing on the wiki:
http://wiki.tdwg.org/twiki/bin/view/TAG/LsidVocs
This is currently pretty unstable which is why I have not been shouting about it yet. The page is self explanatory but needs review and a few minor changes for lessons learned so far.
If you would like to explore and have a play the TaxonName vocabulary is the most stable and advanced.
Wiki Page: http://wiki.tdwg.org/twiki/bin/view/TAG/TaxonNameLsidVoc
RDF/OWL vocabulary: http://rs.tdwg.org/ontology/voc/TaxonName
In a modern browser this is rendered as HTML human readable version of the documentation but if you do view source or request it with an application that doesn't honor the xslt instruction you will see the actual XML serialized OWL. The XSLT used to generate the documentation needs work - not least branding. If anyone would like to help with this that would kind. The HTML rendering is used in the Firefox LSID browser quite nicely as a kind of online help.
The other two links in the resources section of the wiki page point to 1) an XML Schema that will generate XML documents that comply to the OWL vocabulary 2) an example document.
The XML Schema is complex because the technology is a little 'challenged' when it comes to validating documents with multiple namespaces. You need to have a separate schema for every namespace which means that the TaxonName schema has 5 imports for starters and one of those imports has a further import. Once you have the framework for handling the things in place though it all becomes possible and the user doesn't have to see it all.
Importantly you should currently use the schema from where it is located. You can open it in OxygenXML and presumably in XML Spy from its current location http://rs.tdwg.org/ontology/voc/xsd/TaxonName/ schema.xsd and browse around the schema. A downloadable version will be done in the future if needed.
If you create a document based on this schema in Spy or Oxygen it will work fine but the code will look terrible because they don't seem to handle the namespace prefixing very well. This is one of the reasons the template document is supplied. Download and use as the template to mess with instance documents.
[caveat - the most common error with the template file is that I haven't changed the schema location from local (in my dev environment) to absolute. This is quite easy to correct and I'll put some catch in there to stop me doing it soon]
Now the big caveat! The XML Schemas under voc/xsd are doomed to die in the near future - so make the most of them. I have been working with the TAPIR team on getting TAPIR to serve valid RDF based on these XML Schemas and thanks the teams genius it seems to be working. The significance of this is obvious as it can potentially join the schema and semantic based worlds. One would theoretically be able to request RDF from a provider who has only mapped ABCD 2.06 and doesn't know anything about RDF. But I won't blow the trumpets and bang the gong until it is really shown to work with real data and we are more fully aware of any issues.
One known issue is that TAPIR providers don't support all of XML Schema and don't like recursive structures. For this reason I am re- engineering the schemas under voc/xsd and putting them under http:// rs.tdwg.org.uk/ontology/voc/tapir where they will continue to work as advertised above. Other resources required for running TAPIR queries (filters and concept alias' etc) will also be placed in this location.
There is a TAPIR developers workshop in 12 - 15 February (in romantic Copenhagen for Valentine's day) that we are working towards. After that workshop we will no doubt know more about how feasible the whole strategy is and the file structure will become more stable.
We do our washing in public so you can see it all unfold on the http://rs.tdwg.org/ontology/voc space but unfortunately you can't get directory listings. This is because we are using hash name spacing and have to have a rewrite rule in there so that http://rs.tdwg.org/ ontology/voc/TaxonName#specificEpithet will resolve to the right place (see W3C best practice document). Interesting files should be linked to from the wiki or other files though.
This email is far longer than I intended but I hope it puts you in the picture.
All the best,
Roger
On 27 Jan 2007, at 04:17, Bob Morris wrote:
I'm eager to study these in detail. In the case of the XML-Schema representations, which I want to try to incorporate in several schemas, the import Schema Locations are relative and so it would be very helpful to have some kind of access to the actual schemas used in the imports. The most robust might be public read access to the SVN server holding these schemas.
Bob
-- Robert A. Morris Professor of Computer Science UMASS-Boston http://www.cs.umb.edu/~ram phone (+1)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
participants (2)
-
Bob Morris
-
Roger Hyam