[tdwg-tapir] conceptual binding

Javier de la Torre jatorre at gmail.com
Fri Mar 3 13:04:28 CET 2006 

Hi Markus,

No. I was just thinking in adding something like Location Paths
(http://www.w3.org/TR/xpath#location-paths) or we could make use of
what the OGC defines in WFS:
>>>From WFS specifications (1.0.0 and 1.1.0)
"""
This specification does not require a WFS implementation to support
the full XPath
language.  In order to keep the implementation entry cost as low as
possible, this
specification mandates that a WFS implementation must support the
following subset of
the XPath language:
1. A WFS implementation must support abbreviated relative location paths.
2. Relative location paths are composed of one or more steps separated
by the path
separator '/'.
3. The first step of a relative location path may correspond to the
root element of the
feature property being referenced or to the root element of the
feature type with
the next step corresponding to the root element of the feature property being
referenced.
4. Each subsequent step in the path must be composed of the abbreviated form of
the child:: axis specifier and the name of the feature property encoded as the
principal node type of element.  The abbreviated form of the child::
axis specifier
is to simply omit the specifier from the location step.
5. Each step in the path may optionally contain a predicate composed of the
predicate delimiters '[' and ']' and a number indicating which child
of the context
node is to be selected.  This allows feature properties that may be
repeated to be
specifically referenced.
6. The final step in a path may optionally be composed of the
abbreviated form of
the attribute:: axis specifier, '@', and the name of a feature
property encoded as
the principal node type of attribute.
"""
In the WFS schema there is a type called XlinkPropertyName to care of
this, but I don't know if this is suitable for us...

The other possibility is to set it to xsd:string and in the
documentation explain that the implementation is free to define up to
which level they want to support Xpath there and maybe define the
minimum as we had before.

Javier.

On 3/3/06, "Döring, Markus" <m.doering at bgbm.org> wrote:
> Well, what do you consider a proper xpath type?
> I think we can add some basic things to our simple pattern. But are you also thinking of adding different axes, functions and all this? Things I could see to be allowed are:
>
> (pre:)qname Selects all child nodes named like this (optionally qualified with prefixes)
> /           Selects from the root node
> //          Selects nodes in the document from the current node that match the selection no matter where they are
> ..          Selects the parent of the current node
> @           Selects attributes
> Predicates:
> [i]             Select ith node
> [last()-1]      Select second-last node
> [position()<3]  Select all nodes before the third
>
>
>
> But that already means we could get a list of matching nodes from the xpath. So a simple mapping becomes a mapping to a list of nodes - essentially multiple single mappings. Gregor was actually looking for this in the recursive SDD.
>
> Is this overkill already?
> Markus
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: tdwg-tapir-bounces at lists.tdwg.org [mailto:tdwg-tapir-bounces at lists.tdwg.org] Im Auftrag von Javier privat
> Gesendet: Donnerstag, 2. März 2006 19:48
> An: Renato De Giovanni
> Cc: tdwg-tapir at lists.tdwg.org
> Betreff: Re: [tdwg-tapir] conceptual binding
>
> 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 at 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">
> >>>>     <gml:featureMember>
> >>>>         <gcp:accession fid="accession.12">
> >>>>             <gcp:GermplasmID>12</gcp:GermplasmID>
> >>>>             <gcp:FAOInstituteCode>ES</gcp:FAOInstituteCode>
> >>>>             <gcp:FullScientificName>Quercus 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 at lists.tdwg.org
> > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>
>

More information about the tdwg-tag mailing list