Re: [tdwg-tapir] Tapir > Capabilities > Schemas > Concepts
Roger, you are right in your core thoughts. If we do not allow dynamic views we dont need to expose the mapped conceptual schema "concepts". But thats only the case if we treat the static views as the source of our concepts. So yuo would have to use only those static view concepts (may I call them "local" concepts as defined in the local/inline view) in your request for filters. You couldnt request a darwincore record and specify a filter from abcd for example.
One more thing about the concepts: their id or "path" attribute looks like an xpath, but it is not! It is treated as a unique string and nothing more. So there is no implied parent/child relationship between any concepts - they are just a list of independent ids.
If a concept is searchable (default=true), then you can use it in a filter. If its not searchable, you can still use it in the response structure! Theres another attribute called mandatory which a provider can set to indicate that this concept is required to be rpesent in a response structure. Useful to force people to include some IPR for example.
Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Roger Hyam Gesendet: Donnerstag, 3. November 2005 14:17 An: tdwg-tapir@lists.tdwg.org Betreff: [tdwg-tapir] Tapir > Capabilities > Schemas > Concepts
I am a little confused as to what is included in the capabilities response under capabilities/schemas/schema.
The annotation says:
"Each known and mapped concept of a schema listed with a boolean flag indicating if its searchable (default = true)."
I have a genus field in my database and I map it to the following concept:
<concept path="/DataSet/TaxonNames/TaxonName/CanonicalName/Genus" searchable="true" />
Should I also include the parent concepts:
<concept path="/DataSet/TaxonNames/TaxonName/CanonicalName" searchable="false" /> <concept path="/DataSet/TaxonNames/TaxonName" searchable="false" /> <concept path="/DataSet/TaxonNames" searchable="false" /> <concept path="/DataSet" searchable="false" />
or are they implied? I presume if they are included then they aren't searchable as they can't be used to build filters.
Does this:
<concept path="/DataSet/TaxonNames/TaxonName/CanonicalName/Genus" searchable="true" />
mean:
* This concept has been mapped to data and can be used in arbitrary response structures and filters in combination with concepts from any of the other conceptual schemas listed in here.
If so is the entire schemas section of capabilities response optional if arbitrary views are not supported? Both the schemas and concepts are given in views anyhow - so do we need to list them here?
Your thoughts most appreciated - I may just have the wrong end of the stick.
Roger
Markus,
Thanks for this. Yes - of course I was not thinking of concepts as just string identifiers.
I think the other problem may be resolved by the granularity of access point. An access point should really be a single set of semantically linked data.
Should one access point contain concepts that it can't link together semantically in a single request?
Thanks,
Roger
Döring, Markus wrote:
Roger, you are right in your core thoughts. If we do not allow dynamic views we dont need to expose the mapped conceptual schema "concepts". But thats only the case if we treat the static views as the source of our concepts. So yuo would have to use only those static view concepts (may I call them "local" concepts as defined in the local/inline view) in your request for filters. You couldnt request a darwincore record and specify a filter from abcd for example.
One more thing about the concepts: their id or "path" attribute looks like an xpath, but it is not! It is treated as a unique string and nothing more. So there is no implied parent/child relationship between any concepts - they are just a list of independent ids.
If a concept is searchable (default=true), then you can use it in a filter. If its not searchable, you can still use it in the response structure! Theres another attribute called mandatory which a provider can set to indicate that this concept is required to be rpesent in a response structure. Useful to force people to include some IPR for example.
Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Roger Hyam Gesendet: Donnerstag, 3. November 2005 14:17 An: tdwg-tapir@lists.tdwg.org Betreff: [tdwg-tapir] Tapir > Capabilities > Schemas > Concepts
I am a little confused as to what is included in the capabilities response under capabilities/schemas/schema.
The annotation says:
"Each known and mapped concept of a schema listed with a boolean flag indicating if its searchable (default = true)."
I have a genus field in my database and I map it to the following concept:
<concept path="/DataSet/TaxonNames/TaxonName/CanonicalName/Genus" searchable="true" />
Should I also include the parent concepts:
<concept path="/DataSet/TaxonNames/TaxonName/CanonicalName" searchable="false" /> <concept path="/DataSet/TaxonNames/TaxonName" searchable="false" /> <concept path="/DataSet/TaxonNames" searchable="false" /> <concept path="/DataSet" searchable="false" />
or are they implied? I presume if they are included then they aren't searchable as they can't be used to build filters.
Does this:
<concept path="/DataSet/TaxonNames/TaxonName/CanonicalName/Genus" searchable="true" />
mean:
- This concept has been mapped to data and can be used in arbitrary response structures and filters in combination with concepts from any of the other conceptual schemas listed in here.
If so is the entire schemas section of capabilities response optional if arbitrary views are not supported? Both the schemas and concepts are given in views anyhow - so do we need to list them here?
Your thoughts most appreciated - I may just have the wrong end of the stick.
Roger
Hi,
Just to add a few comments about the subject... The idea of TapirLite did change a bit the way that the protocol has been originally conceived, so I think it's important to do that kind of revision in some parts of it.
I can see that a list of mapped concepts can be more useful if dynamic searches or inventories are allowed. But even for TapirLite, it could be interesting to advertise which globally understood concepts map to local data. So, yes, there could be cases when some concepts are advertised but are not used by any of the static views. But I suppose that this information could be of interest to view writers, for example. Especially if we're thinking about well-defined view libraries being prepared by someone.
I can't think of any other reasons right now, but I believe there's a value in knowing what parts of a global data model are "potentially" accessible from a particular data provider...
Regards, -- Renato
On 3 Nov 2005 at 16:20, Döring, Markus wrote:
Roger, you are right in your core thoughts. If we do not allow dynamic views we dont need to expose the mapped conceptual schema "concepts". But thats only the case if we treat
the
static views as the source of our concepts. So yuo would have to
use
only those static view concepts (may I call them "local" concepts
as
defined in the local/inline view) in your request for filters. You couldnt request a darwincore record and specify a filter from abcd
for
example.
One more thing about the concepts: their id or "path" attribute
looks
like an xpath, but it is not! It is treated as a unique string and nothing more. So there is no implied parent/child relationship
between
any concepts - they are just a list of independent ids.
If a concept is searchable (default=true), then you can use it in a filter. If its not searchable, you can still use it in the response structure! Theres another attribute called mandatory which a
provider
can set to indicate that this concept is required to be rpesent in
a
response structure. Useful to force people to include some IPR for example.
Markus
participants (3)
-
"Döring, Markus" -
Renato De Giovanni -
Roger Hyam