wiki-archive/twiki/data/TAPIR/ConceptAlias.txt,v

106 lines
3.3 KiB
Plaintext

head 1.5;
access;
symbols;
locks; strict;
comment @# @;
1.5
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.4;
1.4
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.3;
1.3
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.2;
1.2
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next 1.1;
1.1
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
branches;
next ;
desc
@Initial revision
@
1.5
log
@Revision 5
@
text
@In TAPIR, concepts are atomic and can be represented with fully qualified names. If a TAPIR implementation is aware of a ConceptNameServer, then one can substitute a ConceptAlias for a FullyQualifiedConceptName.
A concept name can technically be any string known by the ConceptNameServer, so long as that string is unique across all concepts in all schema known by that ConceptNameServer. However, it is helpful to follow a convention for concept aliases.
The convention is, when constructing aliases to concepts from XML schema, to have the alias be the local name of the element that represents the concept followed by @@ and a string that identified the namespace of the XML Schema in which the concept is defined. The namespace identifying string should be a short string that uniquely identifies the namespace from other namespaces exported by XML schema known by the ConceptNameServer.
Guarantees that concept aliases are unique must be made by the ConceptNameServer.
So, if a ConceptNameServer knows about the fully qualified concept name `http://www.tdwg.org/schema/abcd/1.20/DataSets/DataSet/OriginalSource/SourceName`, it might also define the concept alias for this concept to be `SourceName@@abcd12`
The advantage given by the use of aliases (which are much shorter than their fully qualified counterparts) is made evident when one makes a search request to a TAPIR service using parameterized GetInvokedOperations
@
1.4
log
@Revision 4
@
text
@d9 1
a9 1
So, if a ConceptNameServer knows about the fully qualified concept name `http://www.tdwg.org/schema/abcd/1.20#/DataSets/DataSet/OriginalSource/SourceName`, it might also define the concept alias for this concept to be `SourceName@@abcd12`
@
1.3
log
@Revision 3
@
text
@d9 1
a9 1
So, if a ConceptNameServer knows about the fully qualified concept name http://www.tdwg.org/schema/abcd/1.20#/DataSets/DataSet/OriginalSource/SourceName, it might also define the concept alias for this concept to be SourceName@@abcd12
@
1.2
log
@Revision 2
@
text
@d5 1
a5 1
The convention is, when constructing aliases to concepts from XML schema, to have the alias be the local name of the element that represents the concept followed by @@ and a string that identified the namespace of the XML Schema in which the concept is defined. The namespace identifying string should be a short string that uniquely identifies the namespace from other namespaces exported by XML schema known by the ConceptNameService.
d7 1
a7 1
Guarantees that concept aliases are unique must be made by the ConceptNameService.
d9 1
a9 1
So, if a ConceptNameService knows about the fully qualified concept name http://www.tdwg.org/schema/abcd/1.20#/DataSets/DataSet/OriginalSource/SourceName, it might also define the concept alias for this concept to be SourceName@@abcd12
@
1.1
log
@Initial revision
@
text
@d1 11
a11 1
Describe ConceptAlias here.
@