Hello, I recently added support for schema imports in pywrapper mainly to support multiple namespaces in the repsonse. Me (and Javier) wanted to allow something like this:
<wfs:FeatureCollection xmlns:wfs="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml" xmlns:gcp="http://www.ipgri.org/schemas/gcp_passport_gml/1.0%22%3E gml:featureMember <gcp:accession fid="accession.12"> gcp:GermplasmID12</gcp:GermplasmID> gcp:FAOInstituteCodeES</gcp:FAOInstituteCode> gcp:FullScientificNameQuercus ilex</gcp:FullScientificName> </gcp:accession> </gml:featureMember> </wfs:FeatureCollection>
Here comes my problem: How do we refer to the FullScientificName concept in TAPIR?
As a convention for schemas we said to create the fully qualified concept from the namespace and the simple xpath to the element. So somethinkg like this:
http://www.opengis.net/wfs#/FeatureCollection/featureMember/accession/FullSc...
A real xpath to that element would of course include several namespaces: /wfs:FeatureCollection/gml:featureMember/gcp:accession/gcp:FullScientificName
Could it be that we never need to refer to "compound" concepts anyway? A provider would probably map his db to the GCP schema alone. The WFS response is only the responded view/data model and we would still just use gcp#accession/FullScientificName as the qualified concept in filters. This is also true for our simple extension schemas I think (EFG for ABCD, all extensions for DwC). But arent there other cases?
Thanks, Markus
Hi,
I think this is not only an issue on filters, is also on mappings. In the mapping section of the outputModel the path attribute of the nodes shouldn't be also qualified? Is there cases that without qualifying we will have problems? Imagine you have in the outputModel something like:
... gcp:FullScientificNameQuercus ilex</gcp:FullScientificName> abcd:FullScientificNameQuercus ilex L.</abcd:FullScientificName> ...
I know it is maybe not a good example, but I hope is clear.
This reminds me also a message from Roger before Christmas about using RDF with TAPIR.
"Tapir has the intention of combining separate 'concepts' (which implies different namespaces) into a single output model but do the concepts all have to be mapped into a single namespace to make the thing workable?"
If I understood the question correctly, the answer is no after import is something supported.
Javier.
Yep. This looks like good news to me. Well done Markus. I presume this enables more RDF like response structures which is great - though I don't have a time to look at it in detail just at this moment I am afraid.
I am sorry that I am still slow on the mapping of elements in conceptual schemas to concepts in data sources to response structures within Tapir so I will not comment further on how the mapping is done.
Good luck,
Roger
Javier de la Torre wrote:
Hi,
I think this is not only an issue on filters, is also on mappings. In the mapping section of the outputModel the path attribute of the nodes shouldn't be also qualified? Is there cases that without qualifying we will have problems? Imagine you have in the outputModel something like:
... gcp:FullScientificNameQuercus ilex</gcp:FullScientificName> abcd:FullScientificNameQuercus ilex L.</abcd:FullScientificName> ...
I know it is maybe not a good example, but I hope is clear.
This reminds me also a message from Roger before Christmas about using RDF with TAPIR.
"Tapir has the intention of combining separate 'concepts' (which implies different namespaces) into a single output model but do the concepts all have to be mapped into a single namespace to make the thing workable?"
If I understood the question correctly, the answer is no after import is something supported.
Javier.
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
Hi Markus,
This is really good news for the PyWrapper!
Now concerning your question, I think we should really try to avoid defining concepts with compound XML schemas. It's a lot cleaner and more elegant using gcp#accession/FullScientificName to map local databases and to use in filters. As you said, the WFS response would just be one of the possible output models making use of the concepts.
The real xpaths to WFS elements (including namespaces) would only be used in the output model mapping section:
<node path="/wfs:FeatureCollection/gml:featureMember/gcp:accession/gcp:FullS cientificName"> <concept id="gcp#accession/FullScientificName"/> </node>
Best Regards, -- Renato
On 28 Feb 2006 at 11:38, "Döring, Markus" wrote:
Hello, I recently added support for schema imports in pywrapper mainly to support multiple namespaces in the repsonse. Me (and Javier) wanted to allow something like this:
<wfs:FeatureCollection xmlns:wfs="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml" xmlns:gcp="http://www.ipgri.org/schemas/gcp_passport_gml/1.0%22%3E gml:featureMember <gcp:accession fid="accession.12"> gcp:GermplasmID12</gcp:GermplasmID> gcp:FAOInstituteCodeES</gcp:FAOInstituteCode> gcp:FullScientificNameQuercus ilex</gcp:FullScientificName> </gcp:accession> </gml:featureMember> </wfs:FeatureCollection>
Here comes my problem: How do we refer to the FullScientificName concept in TAPIR?
As a convention for schemas we said to create the fully qualified concept from the namespace and the simple xpath to the element. So somethinkg like this:
http://www.opengis.net/wfs#/FeatureCollection/featureMember/accession/FullSc...
A real xpath to that element would of course include several namespaces: /wfs:FeatureCollection/gml:featureMember/gcp:accession/gcp:FullScientificName
Could it be that we never need to refer to "compound" concepts anyway? A provider would probably map his db to the GCP schema alone. The WFS response is only the responded view/data model and we would still just use gcp#accession/FullScientificName as the qualified concept in filters. This is also true for our simple extension schemas I think (EFG for ABCD, all extensions for DwC). But arent there other cases?
Thanks, Markus
Uhmm...
Did I understand this incorrectly? The change in the mapping would only be qualifying concepts in the path attribute not in the concept ids.
I think we agree on that the concept ids does not have anything to do with XML schema or Xpaths no? Is just "by coincide" that we are using something "similar".
Javier.
On 3/3/06, Renato De Giovanni renato@cria.org.br wrote:
Hi Markus,
This is really good news for the PyWrapper!
Now concerning your question, I think we should really try to avoid defining concepts with compound XML schemas. It's a lot cleaner and more elegant using gcp#accession/FullScientificName to map local databases and to use in filters. As you said, the WFS response would just be one of the possible output models making use of the concepts.
The real xpaths to WFS elements (including namespaces) would only be used in the output model mapping section:
<node path="/wfs:FeatureCollection/gml:featureMember/gcp:accession/gcp:FullS cientificName">
<concept id="gcp#accession/FullScientificName"/> </node>
Best Regards,
Renato
On 28 Feb 2006 at 11:38, "Döring, Markus" wrote:
Hello, I recently added support for schema imports in pywrapper mainly to support multiple namespaces in the repsonse. Me (and Javier) wanted to allow something like this:
<wfs:FeatureCollection xmlns:wfs="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml" xmlns:gcp="http://www.ipgri.org/schemas/gcp_passport_gml/1.0%22%3E gml:featureMember <gcp:accession fid="accession.12"> gcp:GermplasmID12</gcp:GermplasmID> gcp:FAOInstituteCodeES</gcp:FAOInstituteCode> gcp:FullScientificNameQuercus ilex</gcp:FullScientificName> </gcp:accession> </gml:featureMember> </wfs:FeatureCollection>
Here comes my problem: How do we refer to the FullScientificName concept in TAPIR?
As a convention for schemas we said to create the fully qualified concept from the namespace and the simple xpath to the element. So somethinkg like this:
http://www.opengis.net/wfs#/FeatureCollection/featureMember/accession/FullSc...
A real xpath to that element would of course include several namespaces: /wfs:FeatureCollection/gml:featureMember/gcp:accession/gcp:FullScientificName
Could it be that we never need to refer to "compound" concepts anyway? A provider would probably map his db to the GCP schema alone. The WFS response is only the responded view/data model and we would still just use gcp#accession/FullScientificName as the qualified concept in filters. This is also true for our simple extension schemas I think (EFG for ABCD, all extensions for DwC). But arent there other cases?
Thanks, Markus
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
Hi Javier,
From the current TAPIR schema, concept ids follow the
"qualifiedConceptIdType", which is explained as:
"A simpleType to represent qualified concept identifiers. This can either be the full format NAMESPACE#LOCAL_CONCEPT or an alias which can be any string."
So you're right that local concepts may not use XPath. It's a choice. I was just following Markus examples - no intention to suggest how the "gcp" conceptual schema should identify its concepts.
Now looking at the "simpleXPathType" (used by the node's path attribute) it seems that the string restriction does not allow for namespace prefixes. So I guess this is something that needs to be fixed in the schema.
Best Regards, -- Renato
On 2 Mar 2006 at 17:11, Javier de la Torre wrote:
Uhmm...
Did I understand this incorrectly? The change in the mapping would only be qualifying concepts in the path attribute not in the concept ids.
I think we agree on that the concept ids does not have anything to do with XML schema or Xpaths no? Is just "by coincide" that we are using something "similar".
Javier.
On 3/3/06, Renato De Giovanni renato@cria.org.br wrote:
Hi Markus,
This is really good news for the PyWrapper!
Now concerning your question, I think we should really try to avoid defining concepts with compound XML schemas. It's a lot cleaner and more elegant using gcp#accession/FullScientificName to map local databases and to use in filters. As you said, the WFS response would just be one of the possible output models making use of the concepts.
The real xpaths to WFS elements (including namespaces) would only be used in the output model mapping section:
<node path="/wfs:FeatureCollection/gml:featureMember/gcp:accession/gcp:FullS cientificName">
<concept id="gcp#accession/FullScientificName"/> </node>
Best Regards,
Renato
On 28 Feb 2006 at 11:38, "Döring, Markus" wrote:
Hello, I recently added support for schema imports in pywrapper mainly to support multiple namespaces in the repsonse. Me (and Javier) wanted to allow something like this:
<wfs:FeatureCollection xmlns:wfs="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml" xmlns:gcp="http://www.ipgri.org/schemas/gcp_passport_gml/1.0%22%3E gml:featureMember <gcp:accession fid="accession.12"> gcp:GermplasmID12</gcp:GermplasmID> gcp:FAOInstituteCodeES</gcp:FAOInstituteCode> gcp:FullScientificNameQuercus ilex</gcp:FullScientificName> </gcp:accession> </gml:featureMember> </wfs:FeatureCollection>
Here comes my problem: How do we refer to the FullScientificName concept in TAPIR?
As a convention for schemas we said to create the fully qualified concept from the namespace and the simple xpath to the element. So somethinkg like this:
http://www.opengis.net/wfs#/FeatureCollection/featureMember/accession/FullSc...
A real xpath to that element would of course include several namespaces: /wfs:FeatureCollection/gml:featureMember/gcp:accession/gcp:FullScientificName
Could it be that we never need to refer to "compound" concepts anyway? A provider would probably map his db to the GCP schema alone. The WFS response is only the responded view/data model and we would still just use gcp#accession/FullScientificName as the qualified concept in filters. This is also true for our simple extension schemas I think (EFG for ABCD, all extensions for DwC). But arent there other cases?
Thanks, Markus
Hi,
Now looking at the "simpleXPathType" (used by the node's path attribute) it seems that the string restriction does not allow for namespace prefixes. So I guess this is something that needs to be fixed in the schema.
Actually the problem with the simpleXpathType arise when I did the example outputModel, it does not validate against the schema because I used ns prefixes.
Maybe my sentence was incorrect, I wanted to say "The change in the mapping section is only in allowing (forcing?) qualifies paths in the node element"
Actually I think pywrapper would not complain of the lack of ns prefixes there (probably the other way around :D ), but in the unlikely event that the ns resolve ambiguities then we are in troubles.
And actually I don't know why this path can not be an xpath. pywrapper and Digir will not be able to undertand complicate xpaths, but maybe other implementations can, and I don't see what is the problem if the provider arise and error like "Sorry xpath in the mapping section of the outputModel not understood".
Imagine a TAPIR implementation that allows you to do a mapping to the second element </a>using xpath expressions. We would be able to do mappings to structures like:
<a> <b/> <b>content here</b> </a>
So here is my proposal: change the simpleXPathType to a proper XpathType.
Javier.
Best Regards,
Renato
On 2 Mar 2006 at 17:11, Javier de la Torre wrote:
Uhmm...
Did I understand this incorrectly? The change in the mapping would only be qualifying concepts in the path attribute not in the concept ids.
I think we agree on that the concept ids does not have anything to do with XML schema or Xpaths no? Is just "by coincide" that we are using something "similar".
Javier.
On 3/3/06, Renato De Giovanni renato@cria.org.br wrote:
Hi Markus,
This is really good news for the PyWrapper!
Now concerning your question, I think we should really try to avoid defining concepts with compound XML schemas. It's a lot cleaner and more elegant using gcp#accession/FullScientificName to map local databases and to use in filters. As you said, the WFS response would just be one of the possible output models making use of the concepts.
The real xpaths to WFS elements (including namespaces) would only be used in the output model mapping section:
<node path="/wfs:FeatureCollection/gml:featureMember/gcp:accession/ gcp:FullS cientificName">
<concept id="gcp#accession/FullScientificName"/> </node>
Best Regards,
Renato
On 28 Feb 2006 at 11:38, "Döring, Markus" wrote:
Hello, I recently added support for schema imports in pywrapper mainly to support multiple namespaces in the repsonse. Me (and Javier) wanted to allow something like this:
<wfs:FeatureCollection xmlns:wfs="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml" xmlns:gcp="http://www.ipgri.org/schemas/gcp_passport_gml/1.0%22%3E gml:featureMember <gcp:accession fid="accession.12"> gcp:GermplasmID12</gcp:GermplasmID> gcp:FAOInstituteCodeES</gcp:FAOInstituteCode> gcp:FullScientificNameQuercus ilex</ gcp:FullScientificName> </gcp:accession> </gml:featureMember> </wfs:FeatureCollection>
Here comes my problem: How do we refer to the FullScientificName concept in TAPIR?
As a convention for schemas we said to create the fully qualified concept from the namespace and the simple xpath to the element. So somethinkg like this:
http://www.opengis.net/wfs#/FeatureCollection/featureMember/ accession/FullScientificName
A real xpath to that element would of course include several namespaces: /wfs:FeatureCollection/gml:featureMember/gcp:accession/ gcp:FullScientificName
Could it be that we never need to refer to "compound" concepts anyway? A provider would probably map his db to the GCP schema alone. The WFS response is only the responded view/data model and we would still just use gcp#accession/FullScientificName as the qualified concept in filters. This is also true for our simple extension schemas I think (EFG for ABCD, all extensions for DwC). But arent there other cases?
Thanks, Markus
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
participants (4)
-
"Döring, Markus" -
Javier de la Torre -
Renato De Giovanni -
Roger Hyam