Re: [PyWrapper-devel] Behold RDF is born unto us!

[Renato De G. <re...@cr...>]

Well done, Roger!

By the way, it would also be interesting to see sparql being used on top
of TAPIR, even not being the most efficient way of doing things.

If you manage to return a bigger RDF document with several names, you can
try this interface to select something with sparql:

http://sparql.org/sparql.html

You just need to know something about sparql and then put the TAPIR url
query in the "target URI" field.

It's really good to confirm that TAPIR can be play in the semantic web world!

Best Regards,
--
Renato

> Happy New Year everyone.
>
> If you have a local pywrapper and have connected the training
> datasource up to a database then you should be able to run this query
> (long URL) perhaps with minor tweaks to the port etc.
>
> http://localhost:8080/pywrapper/pywrapper?
> dsa=training&op=search&envelope=false&model=http://rs.tdwg.org/
> ontology/voc/tapir/outputmodel/TaxonName_001.xml&filter=UnitID@abcd206
> +like+"2422"
>
> What you will get back is (but for one minor minor thing) valid RDF!
>
> After Markus' fix (and after Christmas) I turned to making a real-
> life output model and it is actually quite simple once you have the
> framework in place.
>
> This is still a fairly trivial example but it shows that it is
> possible and I'll continue to build on it up to the workshop.
>
> **WARNING** I am using the identifications table in the training dsa
> as if it contained pure nomenclatural data just because I have the
> TaxonName vocabulary to hand. This is not how the vocabulary should
> or will be used. It is just a test thing. I'll now try and do some
> more sensible things.
>
> The fun part is that I use the mapped ABCD concepts in my output
> model. So we are creating RDF from a datasource that was never
> intended to supply it :) Not sure how possible this will be in real
> life for retrofitting data suppliers who haven't done the mappings to
> the central concepts but is a possibility.
>
> I have one question about Concept Name Servers. It would make sense
> to have a CNS for the TDWG ontology. We could then define the RDF
> generating models and some query templates in it along with their
> associated concepts. We would need some convention to prevent name
> clashes with the alias'.
>
> Can anyone see a problem with this? Will PyWrapper pick up multiple
> CNS and load them all? Has this been tested?
>
> The mapping is fun here because the TAPIR concepts map to db concepts
> through the regular mechanisms but are also mapped, via the namespace
> conventions in the RDF to more general meanings.
>
> I also have a request. If you take the result of running the above
> (it looks like this)
>
> <?xml version="1.0" encoding="UTF-8"?>
>
>
> <RDF xmlns='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
>    <TaxonName xmlns='http://rs.tdwg.org/ontology/voc/TaxonName#'
> about='2422'>
>      <title xmlns='http://purl.org/dc/elements/1.1/'>Calicium
> adspersum Pers. subsp. australe Tibell</title>
>      <genusPart>Calicium</genusPart>
>      <specificEpithet>adspersum</specificEpithet>
>      <infraspecificEpithet>australe</infraspecificEpithet>
>    </TaxonName>
> </RDF>
>
> and cut and paste it into the W3C RDF validator (http://www.w3.org/
> RDF/Validator/) you get a single deprecated warning.
>
> Error: {W102} unqualified use of rdf:about is deprecated.[Line = 5,
> Column = 78]
>
> It seems that PyWrapper isn't putting the namespace in for the
> attribute in the output. I have not looked into it in detail but it
> is specified in the model and other namespace stuff is followed so I
> guess it is a bug (this is the minor minor thing that will come to
> bite us when we need rdf:resource references going).
>
> Could someone with their hands on the code (sorry is that you
> Markus!) look at this one. Then I think we will be really RDF
> compatible.
>
> Many thanks,
>
> All the best,
>
> Roger