wiki-archive/twiki/data/GUID/TdwgLsidApplicabilityStatement.txt,v

head	1.10;
access;
symbols;
locks; strict;
comment	@# @;


1.10
date	2007.08.30.12.10.37;	author RicardoPereira;	state Exp;
branches;
next	1.9;

1.9
date	2007.01.29.18.05.35;	author RicardoPereira;	state Exp;
branches;
next	1.8;

1.8
date	2006.10.15.15.40.52;	author RodericPage;	state Exp;
branches;
next	1.7;

1.7
date	2006.10.12.02.11.54;	author BobMorris;	state Exp;
branches;
next	1.6;

1.6
date	2006.10.12.02.10.32;	author BobMorris;	state Exp;
branches;
next	1.5;

1.5
date	2006.10.11.18.13.54;	author RodericPage;	state Exp;
branches;
next	1.4;

1.4
date	2006.10.11.18.11.55;	author RodericPage;	state Exp;
branches;
next	1.3;

1.3
date	2006.10.11.14.30.45;	author RicardoPereira;	state Exp;
branches;
next	1.2;

1.2
date	2006.10.11.14.30.16;	author RicardoPereira;	state Exp;
branches;
next	1.1;

1.1
date	2006.10.11.13.53.28;	author RicardoPereira;	state Exp;
branches;
next	;


desc
@
.
@


1.10
log
@none
@
text
@%META:TOPICINFO{author="RicardoPereira" date="1188475837" format="1.1" reprev="1.10" version="1.10"}%
---++ TDWG !LSID Applicability Statement

The *TDWG !LSID Applicability Statement* is a draft TDWG standard (soon to be submitted for ratification) that-
   1. provides guidance on how to use LSID to meet specific requirements of the biodiversity information community and
   1. defines how to identify shared data objects in biodiversity information applications using Life Sciences Identifiers (LSID).

This specification summarizes all agreed decisions by the [[http://www.tdwg.org/activities/guid/][TDWG-GUID]] group. 

---+++ Requests for Comments

   * LsidApplicabilityStatementRfC2007Sep - Request for Comments on LSID A.S. from Sep/2007 *(current)*


---+++ Superseded Documents

   * LsidApplicabilityStatementRfC2006Oct - Request for Comments on LSID A.S. from Oct/2006 *(superseded)*



@


1.9
log
@none
@
text
@d1 2
a2 2
%META:TOPICINFO{author="RicardoPereira" date="1170093935" format="1.1" version="1.9"}%
---++ TDWG LSID Applicability Statement
d4 3
a6 1
The TDWG GUID group is now drafting the *TDWG LSID Applicability Statement* which is planed to serve as guideline for implementation of LSID resolvers in biodiversity information applications. This specification will summarize all agreed decisions by the GUID group. 
d8 1
a8 1
See [[http://www.tdwg.gbif.org/uploads/media/TDWG_LSID_Applicability_Statement_11_10_2006.doc][the latest version of the TDWG LSID Applicability Statement]] at the TDWG GUID Website.
d10 1
a10 2
----
---+++ Comments and Discussion
d12 1
a12 2
------
%ICON{bubble}% Subject:	*No mention of testing*     Posted by: Main.RodPage
a13 1
Regarding the document, there is no mention of testing, such as testing that the service is valid, returns standard error codes, and that metadata served is valid RDF (if, indeed, it is RDF).
d15 1
a15 2
------
%ICON{bubble}% Subject:	*No standard use of constraint terms (must, may, etc)*     Posted by: Main.BobMorris on 2006-10-11
d17 1
a17 1
The document seems to mix recommendations with requirements. "Should" is not an imperative. Rod _should_ identify each of his comments so discussion here doesn't get confusing. :-)   Also, I would prefer to see TDWG adopt a specific set of constraint terms across all documents, e.g. those of W3C(?) ("must", "may", "must not", etc. (?))
a19 56
------
%ICON{bubble}% Subject:	*Section 2.1 - first three portions of LSID should be lowercase - why?*     Posted by: Main.RodPage

From the document: _2.1 The first three portions of an LSID (the labels "urn", "lsid", and the authority identification) should all be lowercase, unless a specific need requires them to be otherwise_

What specific need do you imagine could arise? Why not simply say that comparisons of LSIDs are case insenstive, and hence recommend lower case at all times. 

-- Main.BobMorris 2006-10-11 - "urn" and "lsid" are required by [[http://rfc.net/rfc2141.html][rfc2141]], the specification of a urn to be case insensitive. The rest are not (by RFC2141). Section 5 of that rfc permits the "lsid" part to add further syntactic restrictions, such as case insensitivity. Section 8.1.1 of the [[http://www.omg.org/docs/formal/04-12-01.pdf][LSID spec]] requires that the third part, the authority, also be case insensitive, but that the remainder be case sensitive.  Requiring case insensitivity for the rest adds a risk that existing LSID compliant tools could not be used without additional processing and is therefore possibly a bad idea. LSID compliant software could happily generate a urn-compliant label starting "URN" which would then be TDWG-noncompliant. So I disagree with Rod's suggestion, as well as the original suggestion, which although harmless is also mooted by the aforementioned specifications.

-- Main.RodPage - My comment was motivated by concerns that LSIDs that differ in case could be regarded as different, when I think this would be a bad thing. For example, when playing with DOIs in Connotea and SPARQL ([[http://semant.blogspot.com/2006/09/connotea-tags.html][described here]]) I discovered that Connotea makes DOIs lower case, even if the publisher's site has them in uppercase. [[http://www.doi.org/handbook_2000/appendix_1.html][Appendix 1]] of the DOI Handbook makes it clear that DOIs are case insensitive, and that any comparison should first convert all characters 'a'-'z' to lower case. I know that the OMG LSID standard allows the LSID to be case sensitive, but that strikes me as just asking for *trouble*. The reasons given for case sensitivity in LSID were:
   _"This allows LSIDs to be more compatible with RDF URI syntax, and also provides simpler mapping onto existing URLs, which are also case sensitive for their path and query string portions."_

Which strike me as pretty weak (LSIDs are not URLs, and I fail to see what case has to do with URIs in RDF). I guess what I was tyring to say earlier was that I'd be happier with an explicit statement that two LSIDs that differ in case only are, in fact, the same LSID.


------
%ICON{bubble}% Subject:	*Section 2.2 - revision part of LSID should not be used*     Posted by: Main.RodPage

From the document: _2.2 The revision part of the LSID, as explained in the LSID specification, will not be used within the TDWG domain_

Not sure this is sensible. What about GenBank records, which are explicitly versioned? Why not simply allow people to use this feature if they wish? In the case of reproducing experiments, being able to access a version of a record seems useful (that was one of the original goals of LSIDs, I thought). 

Regarding "or what if a version is requested but there is a later version - should you return the latest version?" Surely, if I want version _x_, give me version _x_!

------
%ICON{bubble}% Subject:	*Section 2.3 - Objects must be typed according to the TDWG ontology*     Posted by: Main.RodPage

From the document: _2.3 Objects identified by an LSID must be typed using the TDWG ontology or other well-known vocabularies according to TDWG common architecture_

This presupposes TDWG will get it's act together to make such ontologies available. This sounds like a rate limiting step to me. Nice idea, but do we have to wait to get things started? My assumption is that the community, rather than TDWG itself will drive this.

-- Main.BobMorris on 2006-10-11 - I agree with whoever wrote the above comment. (I think I can guess who :-) )

------
%ICON{bubble}% Subject:	*Section 4 - TDWG DNS SRV Service for LSID Authority Identifications*     Posted by: Main.RodPage

Good idea. Minor comment. Need to be careful when doing this that SRV records match the server software. For example, Index Fungorum's service is broken because the SRV record points to a different port to that required by the server.


------
%ICON{bubble}% Subject:	*Specifying XML as the default representation of RDF for getMetadata()*     Posted by: Main.GregRiccardi on [[http://mailman.nhm.ku.edu/pipermail/tdwg-guid/2006-October/000149.html][mailing list]]

The applicability document says that getMetadata should return RDF. Because getMetadata returns XML, the applicability document is implicitly requiring a specific mapping from RDF to XML. I wonder whether the serialization of RDF as XML is an accepted standard, or whether the requirement for RDF needs clarification.

Possibly the applicability document should explicitly refer to appropriate schemas and/or namespaces. For example, the XML documents produced by my LSID getMetadata services start with an rdf:RDF tag that specifies a variety of namespaces. Those namespaces, plus some implicit XML schema, constrain the serialization of the RDF triples.

Sample list of namespaces:
<verbatim>
<rdf:RDF 
   xmlns:daml="http://www.daml.org/2001/03/daml+oil#" 
   xmlns:owl="http://www.w3.org/2002/07/owl#" 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
</verbatim>

Please comment on whether the applicability document requires additional detail to specify the XML representation of RDF documents that are produced by getMetadata.
@


1.8
log
@Made my comments clear
.
@
text
@d1 1
d11 2
a12 1
Please place your comments in this section, or send an edited version of the MS Word document with Track Changes turned on to ricardo at tdwg.org.
d14 1
a14 3
''Rod Page start''
Some comments below. Follow Bob's suggestion, I've indicated my comments. Incidentally, Wikis seem poor at handling this kind of discusion, which combines annotations and threads. Regarding the document, there is no mention of testing, such as testing that the service is valid, returns standard error codes, and that metadata served is valid RDF (if, indeed, it is RDF).
''Rod Page end''
d16 2
a17 1
Bob Morris: The document seems to mix recommendations with requirements. "Should" is not an imperative. Rod _should_ identify each of his comments so discussion here doesn't get confusing. :-)   Also, I would prefer to see TDWG adopt a specific set of constraint terms across all documents, e.g. those of W3C(?) ("must", "may", "must not", etc. (?) ) BobMorris 2006-10-11
d19 1
a20 1
2.1 * The first three portions of an LSID (the labels "urn", "lsid", and the authority identification) should all be lowercase, unless a specific need requires them to be otherwise*
d22 5
a26 1
''Rod Page start''
a27 1
''Rod Page end''
d29 1
a29 1
"urn" and "lsid" are required by [[http://rfc.net/rfc2141.html][rfc2141]], the specification of a urn to be case insensitive. The rest are not (by RFC2141). Section 5 of that rfc permits the "lsid" part to add further syntactic restrictions, such as case insensitivity. Section 8.1.1 of the [[http://www.omg.org/docs/formal/04-12-01.pdf][LSID spec]] requires that the third part, the authority, also be case insensitive, but that the remainder be case sensitive.  Requiring case insensitivity for the rest adds a risk that existing LSID compliant tools could not be used without additional processing and is therefore possibly a bad idea. LSID compliant software could happily generate a urn-compliant label starting "URN" which would then be TDWG-noncompliant. So I disagree with Rod's suggestion, as well as the original suggestion, which although harmless is also mooted by the aforementioned specifications.  --BobMorris 2006-10-11
d31 2
a32 3
''Rod Page start''
My comment was motivated by concerns that LSIDs that differ in case could be regarded as different, when I think this would be a bad thing. For example, when playing with DOIs in Connotea and SPARQL ([[http://semant.blogspot.com/2006/09/connotea-tags.html][described here]]) I discovered that Connotea makes DOIs lower case, even if the publisher's site has them in uppercase. [[http://www.doi.org/handbook_2000/appendix_1.html][Appendix 1]] of the DOI Handbook makes it clear that DOIs are case insensitive, and that any comparison should first convert all characters 'a'-'z' to lower case. I know that the OMG LSID standard allows the LSID to be case sensitive, but that strikes me as just asking for *trouble*. The reasons given for case sensitivity in LSID were:
   "This allows LSIDs to be more compatible with RDF URI syntax, and also provides simpler mapping onto existing URLs, which are also case sensitive for their path and query string portions." 
a34 1
''Rod Page end''
d36 6
a41 2
2.2 *The revision part of the LSID, as explained in the LSID specification, will not be used within the TDWG domain*
''Rod Page start''
a44 1
''Rod Page end''
d46 4
a50 2
2.3 *Objects identified by an LSID must be typed using the TDWG ontology or other well-known vocabularies according to TDWG common architecture*
''Rod Page start''
a51 1
''Rod Page end''
d53 4
a56 1
I agree with whoever wrote the above comment. (I think I can guess who :-) ) BobMorris 2006-10-11
a57 2
4. *TDWG DNS SRV Service for LSID Authority Identifications (non-normative)*
''Rod Page start''
d59 20
a78 1
''Rod Page end''@


1.7
log
@
.
@
text
@d12 3
a14 2
Rod Page
Some comments below. Also, there is no mention of testing, such as testing that the service is valid, and that metadata served is valid RDF.
d18 4
a21 1
2.1 *2.1. The first three portions of an LSID (the labels "urn", "lsid", and the authority identification) should all be lowercase, unless a specific need requires them to be otherwise*
d23 1
d27 7
d35 1
d39 2
d43 1
d45 1
d50 3
a52 2

Good idea. Minor comment. Need to be careful when doing this that SRV records match the server software. For example, Index Fungorum's service is broken because the SRV record points to a different port to that required by the server.@


1.6
log
@
.
@
text
@d20 1
a20 1
"urn" and "lsid" are required by [[http://rfc.net/rfc2141.html][rfc2141]], the specification of a urn to be case insensitive. The rest are not (by RFC2141). Section 5 of that rfc permits the "lsid" part to add further syntactic restrictions, such as case insensitivity. Section 8.1.1 of the [[http://www.omg.org/docs/formal/04-12-01.pdf][LSID spec]] requires that the third part, the authority, also be case insensitive, but that the remainder be case sensitive.  Requiring case insensitivity for the rest adds a risk that existing LSID compliant tools could not be used without additional processing and is therefore possibly a bad idea. LSID compliant software could happily generate a urn noncompliant label starting "URN" which would then be TDWG-noncompliant. So I disagree with Rod's suggestion, as well as the original suggestion, which although harmless is also mooted by the aforementioned specifications.  --BobMorris 2006-10-11
@


1.5
log
@
.
@
text
@d15 2
d20 2
d30 2
@


1.4
log
@
.
@
text
@d13 1
@


1.3
log
@
.
@
text
@d10 18
a27 1
Please place your comments in this section, or send an edited version of the MS Word document with Track Changes turned on to ricardo at tdwg.org.@


1.2
log
@
.
@
text
@d5 1
a5 1
See the latest version of the [[http://www.tdwg.gbif.org/uploads/media/TDWG_LSID_Applicability_Statement_11_10_2006.doc][TDWG LSID Applibility Statement]] at the TDWG GUID Website.
@


1.1
log
@Initial revision
@
text
@d3 1
a3 1
The TDWG GUID group is now drafting the *TDWG LSID Applibility Statement* which is planed to serve as guideline for implementation of LSID resolvers in biodiversity information applications. This specification will summarize all agreed decisions by the GUID group. 
@