[tdwg-tapir] Darwin & RDF
Dear all, This is clearly a crosscutting issue and I thought about using the TAPIR mailing list for the following reasons: 1) The main people involved with DarwinCore are subscribed here; 2) This issue raised from a TAPIR use case; 3) It can affect all existing TAPIR/DarwinCore providers, as well as all output models based on DarwinCore. As you know, there was a recent release of TapirLink which includes an LSID authority that serves an RDF representation of DarwinCore by default. Everything seems to be working fine, but when I parse the resulting RDF in the W3C validator, I see that the predicates are being displayed as: http://rs.tdwg.org/dwc/dwcoreGenus While in the semantic world the "expected" representation would be something like: http://rs.tdwg.org/dwc/dwcore#Genus Apparently it seems just a cosmetic thing, but after some quick research this "unexpected representation" can cause problems depending on usage and tools: for instance, if it's necessary to perform RDF/XML round-tripping, then semantic web tools may not work if there's no clear separation between the namespace URI and local names, which is normally done by using the fragment identifier. If you're interested, you can find a similar discussion here: http://www.imc.org/atom-syntax/mail-archive/msg16476.html Which has this interesting follow-up: http://www.imc.org/atom-syntax/mail-archive/msg16480.html Since the new DarwinCore version and its extensions are not yet a TDWG standard and may even be subject to other changes, I'm proposing to add the fragment identifier to all Darwin namespaces. Better to do this as soon as possible if we're going to need this in the future. Please let me know if you have any comments, ideas or concerns... It may be the case that this change will affect other things (like the new GBIF REST service) although probably not as much as TAPIR/DarwinCore providers which will need to re-map their databases. Best Regards, -- Renato
Hi Renato, I would favor the use of fragment identifiers for the predicates as it is consistent with their intended use. I expect the difficulty associated with reconfiguration now will be much less than the problems encountered later if this change is not made. Dave V. On Apr 19, 2007, at 08:32, Renato De Giovanni wrote:
Dear all,
This is clearly a crosscutting issue and I thought about using the TAPIR mailing list for the following reasons:
1) The main people involved with DarwinCore are subscribed here; 2) This issue raised from a TAPIR use case; 3) It can affect all existing TAPIR/DarwinCore providers, as well as all output models based on DarwinCore.
As you know, there was a recent release of TapirLink which includes an LSID authority that serves an RDF representation of DarwinCore by default.
Everything seems to be working fine, but when I parse the resulting RDF in the W3C validator, I see that the predicates are being displayed as:
http://rs.tdwg.org/dwc/dwcoreGenus
While in the semantic world the "expected" representation would be something like:
http://rs.tdwg.org/dwc/dwcore#Genus
Apparently it seems just a cosmetic thing, but after some quick research this "unexpected representation" can cause problems depending on usage and tools: for instance, if it's necessary to perform RDF/XML round-tripping, then semantic web tools may not work if there's no clear separation between the namespace URI and local names, which is normally done by using the fragment identifier.
If you're interested, you can find a similar discussion here: http://www.imc.org/atom-syntax/mail-archive/msg16476.html
Which has this interesting follow-up: http://www.imc.org/atom-syntax/mail-archive/msg16480.html
Since the new DarwinCore version and its extensions are not yet a TDWG standard and may even be subject to other changes, I'm proposing to add the fragment identifier to all Darwin namespaces. Better to do this as soon as possible if we're going to need this in the future.
Please let me know if you have any comments, ideas or concerns...
It may be the case that this change will affect other things (like the new GBIF REST service) although probably not as much as TAPIR/DarwinCore providers which will need to re-map their databases.
Best Regards, -- Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
Agreed. Now is the right time for this. 2007/4/18, Dave Vieglais <vieglais@ku.edu>:
Hi Renato, I would favor the use of fragment identifiers for the predicates as it is consistent with their intended use. I expect the difficulty associated with reconfiguration now will be much less than the problems encountered later if this change is not made.
Dave V.
On Apr 19, 2007, at 08:32, Renato De Giovanni wrote:
Dear all,
This is clearly a crosscutting issue and I thought about using the TAPIR mailing list for the following reasons:
1) The main people involved with DarwinCore are subscribed here; 2) This issue raised from a TAPIR use case; 3) It can affect all existing TAPIR/DarwinCore providers, as well as all output models based on DarwinCore.
As you know, there was a recent release of TapirLink which includes an LSID authority that serves an RDF representation of DarwinCore by default.
Everything seems to be working fine, but when I parse the resulting RDF in the W3C validator, I see that the predicates are being displayed as:
http://rs.tdwg.org/dwc/dwcoreGenus
While in the semantic world the "expected" representation would be something like:
http://rs.tdwg.org/dwc/dwcore#Genus
Apparently it seems just a cosmetic thing, but after some quick research this "unexpected representation" can cause problems depending on usage and tools: for instance, if it's necessary to perform RDF/XML round-tripping, then semantic web tools may not work if there's no clear separation between the namespace URI and local names, which is normally done by using the fragment identifier.
If you're interested, you can find a similar discussion here: http://www.imc.org/atom-syntax/mail-archive/msg16476.html
Which has this interesting follow-up: http://www.imc.org/atom-syntax/mail-archive/msg16480.html
Since the new DarwinCore version and its extensions are not yet a TDWG standard and may even be subject to other changes, I'm proposing to add the fragment identifier to all Darwin namespaces. Better to do this as soon as possible if we're going to need this in the future.
Please let me know if you have any comments, ideas or concerns...
It may be the case that this change will affect other things (like the new GBIF REST service) although probably not as much as TAPIR/DarwinCore providers which will need to re-map their databases.
Best Regards, -- Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
Indeed - please proceed. Donald ------------------------------------------------------------ Donald Hobern (dhobern@gbif.org) Deputy Director for Informatics Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ------------------------------------------------------------ On Apr 19, 2007, at 3:22 AM, John R. WIECZOREK wrote:
Agreed. Now is the right time for this.
2007/4/18, Dave Vieglais <vieglais@ku.edu>: Hi Renato, I would favor the use of fragment identifiers for the predicates as it is consistent with their intended use. I expect the difficulty associated with reconfiguration now will be much less than the problems encountered later if this change is not made.
Dave V.
On Apr 19, 2007, at 08:32, Renato De Giovanni wrote:
Dear all,
This is clearly a crosscutting issue and I thought about using the TAPIR mailing list for the following reasons:
1) The main people involved with DarwinCore are subscribed here; 2) This issue raised from a TAPIR use case; 3) It can affect all existing TAPIR/DarwinCore providers, as well as all output models based on DarwinCore.
As you know, there was a recent release of TapirLink which includes an LSID authority that serves an RDF representation of DarwinCore by default.
Everything seems to be working fine, but when I parse the resulting RDF in the W3C validator, I see that the predicates are being displayed as:
http://rs.tdwg.org/dwc/dwcoreGenus
While in the semantic world the "expected" representation would be something like:
http://rs.tdwg.org/dwc/dwcore#Genus
Apparently it seems just a cosmetic thing, but after some quick research this "unexpected representation" can cause problems depending on usage and tools: for instance, if it's necessary to perform RDF/XML round-tripping, then semantic web tools may not work if there's no clear separation between the namespace URI and local names, which is normally done by using the fragment identifier.
If you're interested, you can find a similar discussion here: http://www.imc.org/atom-syntax/mail-archive/msg16476.html
Which has this interesting follow-up: http://www.imc.org/atom-syntax/mail-archive/msg16480.html
Since the new DarwinCore version and its extensions are not yet a TDWG standard and may even be subject to other changes, I'm proposing to add the fragment identifier to all Darwin namespaces. Better to do this as soon as possible if we're going to need this in the future.
Please let me know if you have any comments, ideas or concerns...
It may be the case that this change will affect other things (like the new GBIF REST service) although probably not as much as TAPIR/DarwinCore providers which will need to re-map their databases.
Best Regards, -- Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
No objections at all, go ahead Renato. Ive been reconfiguring my tapirs here today and stumbled quite often across "old" mappings to darwin core 1.0 with NS http://digir.net/ schema/conceptual/darwin/2003/1.0. Those concepts are also in the standard TDWG alias.txt file. What do you think, is there still any need for it with TAPIR or can we remove all reference to the old darwin core and only work with the new one? Anybody of course is free to do create his own alias.txt and models, but should TDWG still provide support for this? -- Markus On 19.04.2007, at 09:50, Donald Hobern wrote:
Indeed - please proceed.
Donald
------------------------------------------------------------ Donald Hobern (dhobern@gbif.org) Deputy Director for Informatics Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ------------------------------------------------------------
On Apr 19, 2007, at 3:22 AM, John R. WIECZOREK wrote:
Agreed. Now is the right time for this.
2007/4/18, Dave Vieglais <vieglais@ku.edu>: Hi Renato, I would favor the use of fragment identifiers for the predicates as it is consistent with their intended use. I expect the difficulty associated with reconfiguration now will be much less than the problems encountered later if this change is not made.
Dave V.
On Apr 19, 2007, at 08:32, Renato De Giovanni wrote:
Dear all,
This is clearly a crosscutting issue and I thought about using the TAPIR mailing list for the following reasons:
1) The main people involved with DarwinCore are subscribed here; 2) This issue raised from a TAPIR use case; 3) It can affect all existing TAPIR/DarwinCore providers, as well as all output models based on DarwinCore.
As you know, there was a recent release of TapirLink which includes an LSID authority that serves an RDF representation of DarwinCore by default.
Everything seems to be working fine, but when I parse the resulting RDF in the W3C validator, I see that the predicates are being displayed as:
http://rs.tdwg.org/dwc/dwcoreGenus
While in the semantic world the "expected" representation would be something like:
http://rs.tdwg.org/dwc/dwcore#Genus
Apparently it seems just a cosmetic thing, but after some quick research this "unexpected representation" can cause problems depending on usage and tools: for instance, if it's necessary to perform RDF/XML round-tripping, then semantic web tools may not work if there's no clear separation between the namespace URI and local names, which is normally done by using the fragment identifier.
If you're interested, you can find a similar discussion here: http://www.imc.org/atom-syntax/mail-archive/msg16476.html
Which has this interesting follow-up: http://www.imc.org/atom-syntax/mail-archive/msg16480.html
Since the new DarwinCore version and its extensions are not yet a TDWG standard and may even be subject to other changes, I'm proposing to add the fragment identifier to all Darwin namespaces. Better to do this as soon as possible if we're going to need this in the future.
Please let me know if you have any comments, ideas or concerns...
It may be the case that this change will affect other things (like the new GBIF REST service) although probably not as much as TAPIR/DarwinCore providers which will need to re-map their databases.
Best Regards, -- Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
Hi Markus, I never used the "old" DarwinCore concepts with TapirLink, except for testing the import of DiGIR PHP configuration. I also don't know if somebody is using it. Anyway, since someone already had the work of adding all DarwinCore concepts in the CNS file, I would suggest to keep them there. At least while the new Darwin is still under the standardization process. But we should definitely rename the label and maybe add some comments there - the old DarwinCore is being shown with a greater version than the new one... Regards, -- Renato On 19 Apr 2007 at 18:00, Markus Döring wrote:
Ive been reconfiguring my tapirs here today and stumbled quite often across "old" mappings to darwin core 1.0 with NS http://digir.net/ schema/conceptual/darwin/2003/1.0. Those concepts are also in the standard TDWG alias.txt file. What do you think, is there still any need for it with TAPIR or can we remove all reference to the old darwin core and only work with the new one? Anybody of course is free to do create his own alias.txt and models, but should TDWG still provide support for this? -- Markus
I would add that once we do have a standard (my charter is under consideration), we should remove the antiquated references to avoid confusion and promote the actual standard. 2007/4/20, Renato De Giovanni <renato@cria.org.br>:
Hi Markus,
I never used the "old" DarwinCore concepts with TapirLink, except for testing the import of DiGIR PHP configuration. I also don't know if somebody is using it.
Anyway, since someone already had the work of adding all DarwinCore concepts in the CNS file, I would suggest to keep them there. At least while the new Darwin is still under the standardization process. But we should definitely rename the label and maybe add some comments there - the old DarwinCore is being shown with a greater version than the new one...
Regards, -- Renato
On 19 Apr 2007 at 18:00, Markus Döring wrote:
Ive been reconfiguring my tapirs here today and stumbled quite often across "old" mappings to darwin core 1.0 with NS http://digir.net/ schema/conceptual/darwin/2003/1.0. Those concepts are also in the standard TDWG alias.txt file. What do you think, is there still any need for it with TAPIR or can we remove all reference to the old darwin core and only work with the new one? Anybody of course is free to do create his own alias.txt and models, but should TDWG still provide support for this? -- Markus
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
I agree that you need a hash in there - but you may consider a slash. This is a good account: http://www.w3.org/TR/swbp-vocab-pub/ It is actually about hosting RDF vocabs but it does cover hash vs slash namespaces and it may be worth looking through it before finally plumping for hashes just incase there is anything in there. The ontology is all # based. All the best, Roger On 18 Apr 2007, at 21:32, Renato De Giovanni wrote:
Dear all,
This is clearly a crosscutting issue and I thought about using the TAPIR mailing list for the following reasons:
1) The main people involved with DarwinCore are subscribed here; 2) This issue raised from a TAPIR use case; 3) It can affect all existing TAPIR/DarwinCore providers, as well as all output models based on DarwinCore.
As you know, there was a recent release of TapirLink which includes an LSID authority that serves an RDF representation of DarwinCore by default.
Everything seems to be working fine, but when I parse the resulting RDF in the W3C validator, I see that the predicates are being displayed as:
http://rs.tdwg.org/dwc/dwcoreGenus
While in the semantic world the "expected" representation would be something like:
http://rs.tdwg.org/dwc/dwcore#Genus
Apparently it seems just a cosmetic thing, but after some quick research this "unexpected representation" can cause problems depending on usage and tools: for instance, if it's necessary to perform RDF/XML round-tripping, then semantic web tools may not work if there's no clear separation between the namespace URI and local names, which is normally done by using the fragment identifier.
If you're interested, you can find a similar discussion here: http://www.imc.org/atom-syntax/mail-archive/msg16476.html
Which has this interesting follow-up: http://www.imc.org/atom-syntax/mail-archive/msg16480.html
Since the new DarwinCore version and its extensions are not yet a TDWG standard and may even be subject to other changes, I'm proposing to add the fragment identifier to all Darwin namespaces. Better to do this as soon as possible if we're going to need this in the future.
Please let me know if you have any comments, ideas or concerns...
It may be the case that this change will affect other things (like the new GBIF REST service) although probably not as much as TAPIR/DarwinCore providers which will need to re-map their databases.
Best Regards, -- Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
Thanks for all feedback. Since there seems to be no big difference between using hash or slash, I took the liberty to change the Darwin namespaces by adding a slash in the end. Although we could have different concept identifiers for RDF and TAPIR, this could probably bring confusion in the future so I suggest we keep them the same. By using a slash, all concept identifiers for TAPIR remained the same and we also followed one of the TAPIR recommendations: avoid using URL special characters in concept identifiers. Otherwise we would need to escape them all the time in TAPIR KVP requests. So, the changes included: * Darwin namespaces. * TAPIR CNS file. * All references to Darwin namespaces in output models and response structures. I also made a new minor release of TapirLink (0.3.1) that correctly generates concept identifiers based on the new Darwin schemas. All TAPIR providers that are using Darwin (core/extensions) as conceptual schema will need to be reconfigured, regardless the software used. Please let me know if you find anything wrong or missing. Best Regards, -- Renato
I agree that you need a hash in there - but you may consider a slash.
This is a good account:
http://www.w3.org/TR/swbp-vocab-pub/
It is actually about hosting RDF vocabs but it does cover hash vs slash namespaces and it may be worth looking through it before finally plumping for hashes just incase there is anything in there.
The ontology is all # based.
All the best,
Roger
On 18 Apr 2007, at 21:32, Renato De Giovanni wrote:
Dear all,
This is clearly a crosscutting issue and I thought about using the TAPIR mailing list for the following reasons:
1) The main people involved with DarwinCore are subscribed here; 2) This issue raised from a TAPIR use case; 3) It can affect all existing TAPIR/DarwinCore providers, as well as all output models based on DarwinCore.
As you know, there was a recent release of TapirLink which includes an LSID authority that serves an RDF representation of DarwinCore by default.
Everything seems to be working fine, but when I parse the resulting RDF in the W3C validator, I see that the predicates are being displayed as:
http://rs.tdwg.org/dwc/dwcoreGenus
While in the semantic world the "expected" representation would be something like:
http://rs.tdwg.org/dwc/dwcore#Genus
Apparently it seems just a cosmetic thing, but after some quick research this "unexpected representation" can cause problems depending on usage and tools: for instance, if it's necessary to perform RDF/XML round-tripping, then semantic web tools may not work if there's no clear separation between the namespace URI and local names, which is normally done by using the fragment identifier.
If you're interested, you can find a similar discussion here: http://www.imc.org/atom-syntax/mail-archive/msg16476.html
Which has this interesting follow-up: http://www.imc.org/atom-syntax/mail-archive/msg16480.html
Since the new DarwinCore version and its extensions are not yet a TDWG standard and may even be subject to other changes, I'm proposing to add the fragment identifier to all Darwin namespaces. Better to do this as soon as possible if we're going to need this in the future.
Please let me know if you have any comments, ideas or concerns...
It may be the case that this change will affect other things (like the new GBIF REST service) although probably not as much as TAPIR/DarwinCore providers which will need to re-map their databases.
Best Regards, -- Renato
participants (6)
-
Dave Vieglais -
Donald Hobern -
John R. WIECZOREK -
Markus Döring -
Renato De Giovanni -
Roger Hyam