https://wiki.esipfed.org/w/api.php?action=feedcontributions&user=JamesGallagher&feedformat=atomEarth Science Information Partners (ESIP) - User contributions [en]2024-03-29T08:56:13ZUser contributionsMediaWiki 1.35.14https://wiki.esipfed.org/w/index.php?title=Software_and_Services_Citations&diff=65406Software and Services Citations2018-07-19T00:18:36Z<p>JamesGallagher: /* Get Involved */</p>
<hr />
<div>__NOTOC__<br />
The purpose of this cluster is to develop recommendations and best practices for software and services citations. <br />
<br />
'''Software Citation Format''' (Please note that this is still under revision)<br />
<br />
Author. Year released. Name. Version. Software publisher. Date software accessed and DOI <br />
<br />
For GIOVANNI: <br />
Giovanni Team. 2015. Giovanni. Ver. 4.21. Goddard, MD, USA. Accessed [YYYY-MM-DD] at https://doi.org/10.5067/…<br />
<br />
Or for the MODIS Land subsetter: ORNL DAAC. 2017. MODIS Collection 6 Land Products Global Subsetting and Visualization Tool. ORNL DAAC, Oak Ridge, TN, USA. Accessed [YYYY-MM-DD]. Subset obtained for [Product name] product at [Lat],[Lon], time period: [Start date] to [End date], and subset size: [Width] x [Height] km. https://doi.org/10.3334/ORNLDAAC/1379<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
===[[/Archived {{PAGENAME}} Events|News]]===<br />
{{:{{PAGENAME}}/Archived {{PAGENAME}} Events}}<br><br />
[[/Archived {{PAGENAME}} Events|Archive]]<br />
<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
===Activities===<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
=== Get Involved===<br />
* '''Email List:''' [http://lists.esipfed.org/mailman/listinfo/esip-citations]<br />
* '''Slack Channel: #softwa-serv-citations''' [https://esip-all.slack.com/messages/C7RALEKNE]<br />
* Next meeting: <br />
** Telecon: [https://global.gotomeeting.com/join/311917189 Goto Meeting] Access Code: 311-917-189<br />
** Dial in: United States: +1 (224) 501-3412, Access Code: 311-917-189<br />
* '''Contact Chair: Jessica Hausman''' ''<Jessica.K.Hausman@jpl.nasa.gov>''<br />
<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
===Resources===<br />
<br />
|}<br />
<br />
<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Software_and_Services_Citations&diff=65401Software and Services Citations2018-07-19T00:14:37Z<p>JamesGallagher: /* Get Involved */</p>
<hr />
<div>__NOTOC__<br />
The purpose of this cluster is to develop recommendations and best practices for software and services citations. <br />
<br />
'''Software Citation Format''' (Please note that this is still under revision)<br />
<br />
Author. Year released. Name. Version. Software publisher. Date software accessed and DOI <br />
<br />
For GIOVANNI: <br />
Giovanni Team. 2015. Giovanni. Ver. 4.21. Goddard, MD, USA. Accessed [YYYY-MM-DD] at https://doi.org/10.5067/…<br />
<br />
Or for the MODIS Land subsetter: ORNL DAAC. 2017. MODIS Collection 6 Land Products Global Subsetting and Visualization Tool. ORNL DAAC, Oak Ridge, TN, USA. Accessed [YYYY-MM-DD]. Subset obtained for [Product name] product at [Lat],[Lon], time period: [Start date] to [End date], and subset size: [Width] x [Height] km. https://doi.org/10.3334/ORNLDAAC/1379<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
===[[/Archived {{PAGENAME}} Events|News]]===<br />
{{:{{PAGENAME}}/Archived {{PAGENAME}} Events}}<br><br />
[[/Archived {{PAGENAME}} Events|Archive]]<br />
<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
===Activities===<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
=== Get Involved===<br />
* '''Email List:''' [http://lists.esipfed.org/mailman/listinfo/esip-citations]<br />
* '''Slack Channel: #softwa-serv-citations''' [https://esip-all.slack.com/messages/C7RALEKNE]<br />
* Next meeting: <br />
** Telecon: [https://global.gotomeeting.com/join/311917189 Goto Meeting] Access Code: 311-917-189<br />
** Dial in: United States: +1 (224) 501-3412, Access Code: 311-917-189<br />
* '''Contact Chair: Jessica Hausman''' <br />
**Contact_Name_Here<br />
<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
===Resources===<br />
<br />
|}<br />
<br />
<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Software_and_Services_Citations&diff=65399Software and Services Citations2018-07-19T00:10:55Z<p>JamesGallagher: /* Get Involved */</p>
<hr />
<div>__NOTOC__<br />
The purpose of this cluster is to develop recommendations and best practices for software and services citations. <br />
<br />
'''Software Citation Format''' (Please note that this is still under revision)<br />
<br />
Author. Year released. Name. Version. Software publisher. Date software accessed and DOI <br />
<br />
For GIOVANNI: <br />
Giovanni Team. 2015. Giovanni. Ver. 4.21. Goddard, MD, USA. Accessed [YYYY-MM-DD] at https://doi.org/10.5067/…<br />
<br />
Or for the MODIS Land subsetter: ORNL DAAC. 2017. MODIS Collection 6 Land Products Global Subsetting and Visualization Tool. ORNL DAAC, Oak Ridge, TN, USA. Accessed [YYYY-MM-DD]. Subset obtained for [Product name] product at [Lat],[Lon], time period: [Start date] to [End date], and subset size: [Width] x [Height] km. https://doi.org/10.3334/ORNLDAAC/1379<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
===[[/Archived {{PAGENAME}} Events|News]]===<br />
{{:{{PAGENAME}}/Archived {{PAGENAME}} Events}}<br><br />
[[/Archived {{PAGENAME}} Events|Archive]]<br />
<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
===Activities===<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
=== Get Involved===<br />
* '''Email List:''' [http://lists.esipfed.org/mailman/listinfo/esip-citations]<br />
* '''Slack Channel: #softwa-serv-citations''' [https://esip-all.slack.com/messages/C7RALEKNE]<br />
* Next meeting: <br />
** Telecon: [https://esipfed.webex.com WebEx] | Password: XXX XXX XX<br />
** Dial In: 1-877-668-4493 Access Code: XXX XXX XX<br />
<br />
* '''Contact Chair: Jessica Hausman''' <br />
**Contact_Name_Here<br />
<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
===Resources===<br />
<br />
|}<br />
<br />
<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=62524WebServices2017-10-04T17:36:55Z<p>JamesGallagher: /* Get Involved */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chairs: [[User:sscott|Soren Scott]], [[JamesGallagher|James Gallagher]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting notes for [https://docs.google.com/document/d/1ioGbmpnVzqkNBcsPZ4MjQ6MxeVE1E-xwtcCfbuRI8a4/edit?usp=sharing 2017 telecons] :'''<br />
<br />
* '''GoTo Meeting/Telecon Instructions:'''<br />
:Please join the meeting from your computer, tablet or smartphone.<br />
:Go to https://www.gotomeeting.com/join/827161661<br />
<br />
:You can also dial in using your phone.<br />
:United States: +1 (646) 749-3131<br />
:Access Code: 827-161-661<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
:* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently looking how to collect and analyze metrics from services, but if you have another WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via Goto Meeting (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting'''<br />
:* We meet on the first Wednesday of each month at 11:00 am Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Slack channel:''' [https://esip-all.slack.com/messages/C3Z42G2HF/ ESIP-all webservices]<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
Here is a draft proposal to ESIP for a project to stage a [https://docs.google.com/document/d/1XVlAEzwJcNNXtXCbfup6tJgK3NYBiMIKi7DW_9GPu9Q/edit?usp=sharing simple metrics gathering service].<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=61958WebServices2017-07-26T02:19:55Z<p>JamesGallagher: /* Activities */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chairs: [[User:sscott|Soren Scott]], [[JamesGallagher|James Gallagher]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting notes for [https://docs.google.com/document/d/1ioGbmpnVzqkNBcsPZ4MjQ6MxeVE1E-xwtcCfbuRI8a4/edit?usp=sharing 2017 telecons] :'''<br />
<br />
* '''GoTo Meeting/Telecon Instructions:'''<br />
:Please join the meeting from your computer, tablet or smartphone.<br />
:Go to https://www.gotomeeting.com/join/827161661<br />
<br />
:You can also dial in using your phone.<br />
:United States: +1 (646) 749-3131<br />
:Access Code: 827-161-661<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
:* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently looking how to collect and analyze metrics from services, but if you have another WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via Goto Meeting (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting'''<br />
:* We meet on the first Wednesday of each month at 1:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Slack channel:''' [https://esip-all.slack.com/messages/C3Z42G2HF/ ESIP-all webservices]<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
Here is a draft proposal to ESIP for a project to stage a [https://docs.google.com/document/d/1XVlAEzwJcNNXtXCbfup6tJgK3NYBiMIKi7DW_9GPu9Q/edit?usp=sharing simple metrics gathering service].<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=57269WebServices2017-07-03T20:25:03Z<p>JamesGallagher: /* Get Involved */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chairs: [[User:sscott|Soren Scott]], [[JamesGallagher|James Gallagher]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting notes for [https://docs.google.com/document/d/1ioGbmpnVzqkNBcsPZ4MjQ6MxeVE1E-xwtcCfbuRI8a4/edit?usp=sharing 2017 telecons] :'''<br />
<br />
* '''GoTo Meeting/Telecon Instructions:'''<br />
:Please join the meeting from your computer, tablet or smartphone.<br />
:Go to https://www.gotomeeting.com/join/827161661<br />
<br />
:You can also dial in using your phone.<br />
:United States: +1 (646) 749-3131<br />
:Access Code: 827-161-661<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
:* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently looking how to collect and analyze metrics from services, but if you have another WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via Goto Meeting (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting'''<br />
:* We meet on the first Wednesday of each month at 1:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Slack channel:''' [https://esip-all.slack.com/messages/C3Z42G2HF/ ESIP-all webservices]<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=56820WebServices2017-03-31T22:47:22Z<p>JamesGallagher: /* Get Involved */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chairs: [[User:sscott|Soren Scott]], [[JamesGallagher|James Gallagher]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting notes for [https://docs.google.com/document/d/1ioGbmpnVzqkNBcsPZ4MjQ6MxeVE1E-xwtcCfbuRI8a4/edit?usp=sharing 2017 telecons] :'''<br />
<br />
* '''GoTo Meeting/Telecon Instructions:'''<br />
:Please join the meeting from your computer, tablet or smartphone.<br />
:Go to https://www.gotomeeting.com/join/827161661<br />
<br />
:You can also dial in using your phone.<br />
:United States: +1 (646) 749-3131<br />
:Access Code: 827-161-661<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
:* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently looking how to collect and analyze metrics from services, but if you have another WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via Goto Meeting (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting'''<br />
:* We meet on the first Monday of each month at 1:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Slack channel:''' [https://esip-all.slack.com/messages/C3Z42G2HF/ ESIP-all webservices]<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=56819WebServices2017-03-31T22:31:39Z<p>JamesGallagher: /* Events */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chairs: [[User:sscott|Soren Scott]], [[JamesGallagher|James Gallagher]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting notes for [https://docs.google.com/document/d/1ioGbmpnVzqkNBcsPZ4MjQ6MxeVE1E-xwtcCfbuRI8a4/edit?usp=sharing 2017 telecons] :'''<br />
<br />
* '''GoTo Meeting/Telecon Instructions:'''<br />
:Please join the meeting from your computer, tablet or smartphone.<br />
:Go to https://www.gotomeeting.com/join/827161661<br />
<br />
:You can also dial in using your phone.<br />
:United States: +1 (646) 749-3131<br />
:Access Code: 827-161-661<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
:* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently on hold here, but if you have a WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via ESIP Webex (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting (''next meeting October 12th, 2015 4pm EDT/1pm PDT'')'''<br />
:* We meet on the second Monday of each month at 4:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=56818WebServices2017-03-31T22:31:16Z<p>JamesGallagher: /* Events */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chairs: [[User:sscott|Soren Scott]], [[JamesGallagher|James Gallagher]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting notes for [https://docs.google.com/document/d/1ioGbmpnVzqkNBcsPZ4MjQ6MxeVE1E-xwtcCfbuRI8a4/edit?usp=sharing 2017 telecons] :'''<br />
<br />
* '''GoTo Meeting/Telecon Instructions:'''<br />
:Please join my meeting from your computer, tablet or smartphone.<br />
:Go to https://www.gotomeeting.com/join/827161661<br />
<br />
:You can also dial in using your phone.<br />
:United States: +1 (646) 749-3131<br />
:Access Code: 827-161-661<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
:* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently on hold here, but if you have a WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via ESIP Webex (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting (''next meeting October 12th, 2015 4pm EDT/1pm PDT'')'''<br />
:* We meet on the second Monday of each month at 4:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=56817WebServices2017-03-31T21:43:37Z<p>JamesGallagher: </p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chairs: [[User:sscott|Soren Scott]], [[JamesGallagher|James Gallagher]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting Agenda and Notes for 2015:'''<br />
:* Upcoming:<br />
::* 2015-10-12: *[[WSC-20151012|Monthly Telecon]]*, 4pm ET<br />
:* Completed:<br />
::* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
<br />
<br />
* '''Webex/Telecon Instructions:'''<br />
:1. Go to https://esipfed.webex.com/<br />
:2. Click the "Meeting Center" tab<br />
:3. Select “Web Services Monthly Call” (or the Activities/Special Topic title).<br />
:4. If a password is required, enter the Meeting Password: '''23136782'''<br />
:5. You can then choose to use your computer to join the audio portion of the meeting, or you can use your phone to dial in.<br />
::* Call-in toll-free number (US/Canada): 1-877-668-4493<br />
::* Attendee access code/Meeting Password: '''23136782'''<br />
<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently on hold here, but if you have a WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via ESIP Webex (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting (''next meeting October 12th, 2015 4pm EDT/1pm PDT'')'''<br />
:* We meet on the second Monday of each month at 4:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=56432WebServices2017-02-03T00:40:57Z<p>JamesGallagher: /* Activities */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chair: [[User:sscott|Soren Scott]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting Agenda and Notes for 2015:'''<br />
:* Upcoming:<br />
::* 2015-10-12: *[[WSC-20151012|Monthly Telecon]]*, 4pm ET<br />
:* Completed:<br />
::* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
<br />
<br />
* '''Webex/Telecon Instructions:'''<br />
:1. Go to https://esipfed.webex.com/<br />
:2. Click the "Meeting Center" tab<br />
:3. Select “Web Services Monthly Call” (or the Activities/Special Topic title).<br />
:4. If a password is required, enter the Meeting Password: '''23136782'''<br />
:5. You can then choose to use your computer to join the audio portion of the meeting, or you can use your phone to dial in.<br />
::* Call-in toll-free number (US/Canada): 1-877-668-4493<br />
::* Attendee access code/Meeting Password: '''23136782'''<br />
<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently on hold here, but if you have a WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via ESIP Webex (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting (''next meeting October 12th, 2015 4pm EDT/1pm PDT'')'''<br />
:* We meet on the second Monday of each month at 4:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
Other suggestions:<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=WebServices&diff=56431WebServices2017-02-03T00:40:01Z<p>JamesGallagher: /* Activities */</p>
<hr />
<div>__NOTOC__<br />
<big><center>'''Welcome to the Web Services Cluster'''</center></big><br />
<center> Contact Cluster Chair: [[User:sscott|Soren Scott]]</center><br />
<br />
===== ESIP Vision =====<br />
<br />
<br />
=====About Us=====<br />
<br />
<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="#FFFFFF"<br />
|bgcolor="lightgreen" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Events==<br />
* '''Meeting Agenda and Notes for 2015:'''<br />
:* Upcoming:<br />
::* 2015-10-12: *[[WSC-20151012|Monthly Telecon]]*, 4pm ET<br />
:* Completed:<br />
::* 2015-09-14: *[[WSC-20150914|Monthly Telecon]]*, 2pm ET<br />
<br />
<br />
<br />
* '''Webex/Telecon Instructions:'''<br />
:1. Go to https://esipfed.webex.com/<br />
:2. Click the "Meeting Center" tab<br />
:3. Select “Web Services Monthly Call” (or the Activities/Special Topic title).<br />
:4. If a password is required, enter the Meeting Password: '''23136782'''<br />
:5. You can then choose to use your computer to join the audio portion of the meeting, or you can use your phone to dial in.<br />
::* Call-in toll-free number (US/Canada): 1-877-668-4493<br />
::* Attendee access code/Meeting Password: '''23136782'''<br />
<br />
<br />
* '''Previous Meeting Agenda and Notes:''' <br />
<br />
|bgcolor="#FFFFBB" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
== Get Involved==<br />
<br />
'''We are currently on hold here, but if you have a WS topic to discuss, get in touch.'''<br />
<br />
:''All meetings are conducted via ESIP Webex (see left-hand side of this page).''<br />
<br />
<br />
* '''Monthly Meeting (''next meeting October 12th, 2015 4pm EDT/1pm PDT'')'''<br />
:* We meet on the second Monday of each month at 4:00pm Eastern.<br />
<br />
<br />
* '''Activities/Special Topic Discussion Meeting:'''<br />
:* We also meet for Activities and Special Topics discussions as necessary.<br />
<br />
<br />
* '''Email List:''' [http://www.lists.esipfed.org/mailman/listinfo/esip-webservices ESIP-WebServices]<br />
* '''Email Archive:''' [http://lists.esipfed.org/pipermail/esip-webservices/ ESIP-WebServices Email Archive]<br />
<br />
<br />
<br />
|}<br />
{| width="100%" cellpadding="0" cellspacing="0" style="zborder-top:1px solid #aaaaaa; border-collapse: collapse;" <br />
|- valign="top" bgcolor="pink"<br />
|bgcolor="lightblue" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Activities==<br />
26 Jan 2017<br />
<br />
We propose that the cluster look at measuring web services patterns of use at sites where large servers are run (e.g., NASA and NOAA). A casual observation is that subsetting services for data access are underused relative to simple file-access, but to qualify and quantify this more data about access patterns are needed. OPeNDAP has some experience with analysis of access data for web services (e.g., server logs) and often has found very telling patterns that can be used to improve server performance, so even if the perception regarding under-utilization it false, there will be significant benefit to the analysis of use.<br />
<br />
If it is the case that web services are underused, we should ask why. Is it because users lack knowledge about them? Or do these services underperform users' expectations?<br />
<br />
ESIP represents an excellent forum for this investigation since it is unique in having people representing all three groups of users (implicitly) mentioned above (end-users, system developers and data center managers).<br />
<br />
* [https://docs.google.com/spreadsheets/d/1rC-6gMnHZtGxH-97P04PxQ0jnccGC-NOwHmSYNWGMdE/edit?usp=sharing Google Doc with potential topics of interest list ]<br />
|bgcolor="pink" style="border: 1px solid gray;padding-left:0.5em;padding-right:0.5em;" width="50%"|<br />
<br />
==Resources (and Other Stuff)==<br />
<br />
[[WebServiceMission|ESIP-Discovery Web Services Mission Statement]]<br />
<br />
|}<br />
<br />
[[category:CollabArea]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Carol_Meyer_Trading_Card&diff=46411Carol Meyer Trading Card2014-04-14T16:04:01Z<p>JamesGallagher: </p>
<hr />
<div>Like we have done for past ESIP president's, we've created a trading card for Carol. Please 'sign the card' by [http://wiki.esipfed.org/index.php?title=Carol_Meyer_Trading_Card&action=edit&section=1 editing the wiki page] below. *<br><br />
<br />
[[Image: ESIP Baseball Card FRONT Carol lg.png|400px]]<br />
[[File:ESIP Baseball Card BACK Carol lg.png|400 px]] <br> <br />
<small><nowiki>*</nowiki> Thank you to Kevin Ward, NASA Earth Observatory, for supplying the background patchwork image, see the [http://nasaesw.strategies.org/interactive/ digital, interactive version here]. </small><br />
<br />
Carol has been with the Foundation Foundation for Earth Science, the secretariat for ESIP, since 2003 and served as the Foundation's Executive Director since 2008. During this time she's championed the ESIP Federation, supported the growth of the ESIP membership to over 150 organizations and has helped raise the visibility and importance of Earth science data and informatics. One of her sayings is 'Let ESIP be ESIP' - this phrase captures the essence of ESIP's community-led nature and because of that flexibility and openness. ESIP has thrived under her watch. <br />
<br />
Carol learned to drive in NYC and NJ and is an expert NYC driver. It is ESIP legend thatWhen the ESIP meeting was at Lamont, Carol drove part of a group fearlessly through NYC to a Yankees' game and drove home in pouring rain. Erin has also been in the car for at least a few u-turns because of their collective challenge navigating. <br />
<br />
In her free time for several summers, Carol played rec volleyball. Those skills came in handy at the Santa Barbara ESIP meeting.<br><br />
[[Image: CarolVolleyball.png]] [[Image: CarolVolleyball_2.jpg|150px]] <br><br />
<small>([https://www.flickr.com/photos/skolr/3701627650/in/set-72157621133449198/ Credit: Bruce Caron, more pics from this meeting])</small><br />
<br />
==Thanks to Carol ==<br />
* Carol, you have been a terrific boss and mentor. You've given me the room and support to grow and for that I'm grateful. I wish you all the best in this new role and am excited to see what comes next! - Erin Robinson<br />
* Thanks for everything you have achieved for ESIP. I am sure that you will spread success wherever you go and whatever you do. You will be missed. All the best with your new endeavor. - Emily Law<br />
* Carol, you made a difference, best wishes for your new endeavors. - Phil Yang<br />
* For more than a decade, Carol poured her enormous talent and energy into making ESIP what it has become. She welcomed new presidents and helped them shine. She made great meetings look easy. She is that person you’d always want to have on your team. We all wish her the best. She leaves ESIP a vibrant organization ready to move ahead with its mission. - Bruce Caron<br />
* Carol, thanks so much for helping build the federation. Wish you the best of everything with your future endeavors. - Ken Keiser<br />
* Carol, you have many wonderful gifts. One is the ability to motivate others to use their own gifts and find their place in the ESIP organization. Your unpretentious and engaging leadership encouraged us; you helped us find connections with each other and with important issues. You are a great friend and role model! - Christine White<br />
* Carol ! Thanks for all the great leadership and dedication to ESIP. All the best! - Ed Armstrong<br />
* Carol, You have been a real anchor, rudder, and sail, all in one, giving us stability, direction, and purpose. Thanks for faultlessly steering this ship on a solid course forward. You will be missed, but with new opportunities come prospects of making significant positive impacts. Keep making significant positive impacts. Good luck - Steve Kempler<br />
* Under the category of "always thinking ahead and always keeping the big picture in mind": Right after the January 2013 meeting, where Ann Bartuska referred me to Simon Liu, I visited with Simon about mutual interests and potential areas of collaboration. A week later, Carol emailed me that she'll be meeting with Simon soon and wanted to find out a bit about my projects with USDA. I told her about my visit with Simon, that I'd be happy to chat about my USDA projects, and that I'd love to see an ESIP group formed to focus on climate change and agriculture. Carol wrote back: "Wow, small world, eh? So, my interest is in connecting to USDA projects/people that are having difficulty using ESIP-member provided data. A Climate & Ag Cluster would be great! Do you want to chair? :)" So, "always thinking ahead and always keeping the big picture in mind" should be "always thinking ahead and always keeping the big picture in mind and never missing an opportunity." :) That was how the Agriculture and Climate Cluster began! Thanks, Carol, for all your help and encouragement. I wish you the best, always! - Bill Teng<br />
* Carol, I just want to tell you how much it means as a student to have someone as encouraging as you in our corner. I wish you the best with everything. - Reid Boehm<br />
* Carol, it has been great working with and around you for your entire 11-year tenure with the Foundation and Federation. Getting to know you and enjoy your combined sense of humor and focus on getting things done has made all of our work together fun and productive. While the version on the baseball card looks nice, I can't help but share the original photo from which the card version was derived - it is a great illustration of the things that make you smile.<br />
<br />
[[File:carolAndGnome.jpg|200px|thumb|left|Carol on the streets of Brussels, enjoying the scenery.]]<br />
<br />
* Carol, I almost can't imagine ESIP without you. Thanks for all the support and encouragement. Best wishes for your new endeavors! May the force be with you! - Ruth Duerr<br />
* Carol, best, best, best to you on your new endeavors. I'm sure you'll bring your special brand of collaboration to your next gig -- and here's hoping we can keep that brand alive with the next chapter of ESIP without you. Thanks for the modeling and inspiration! - Nancy Hoebelheinrich<br />
* Carol, best wishes of everything with your future endeavors. - Yuechen Chi<br />
* Good luck - Annette Schloss<br />
*Carol, Congratulations on your new position. As I have seen during your tenure at the ESIP Federation and Foundation, it has been growing tremendously and has been operating like a well-oiled machine. Many kudos to you on your accomplishments and all the best in your new adventures. - Rama. (H. K. Ramapriyan)<br />
* Carol, Thanks for all your hard work with ESIP and good luck in your new position. - James Gallagher</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38778DCP-42012-03-18T19:33:58Z<p>JamesGallagher: /* Proposed Solution */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset. For this the atom 1.1 ''length'' attribute should be included and its value should be the size of the file in bytes.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URL (dereferenceable)>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# For the OPeNDAP case, the only required ''link'' element is the service endpoint as described in the preceding item.<br />
# It is assumes that every valid OPeNDAP server that implements DAP2 (and the DAP2 implementation is indicated using the ''xlink:role'' attribute) will provide the following response types which do not need to be enumerated. Any DAP2-capable client will know how to access these responses:<br />
#* DAS<br />
#* DDS<br />
#* DODS (this is the 'data' response)<br />
# The following responses are not part of the DAP2 specification but are commonly provided; When they are present and a provider wants to make sure clients know they can be accessed, The ''link'' element will use the following ''rel'' and ''type'' attribute values:<br />
<blockquote><br />
{|class="wikitable"<br />
|-<br />
! Server Response Type<br />
! ''rel''<br />
! ''type''<br />
! ''xlink:arcrole'' <br />
|-<br />
| HTML<br />
| describedby<br />
| text/html<br />
| #html<br />
|-<br />
| info<br />
| describedby<br />
| text/html<br />
| #info<br />
|-<br />
| DDX<br />
| describedby<br />
| application/xml<br />
| #ddx<br />
|-<br />
| RDF<br />
| describedby<br />
| application/rdf+xml<br />
| #rdf<br />
|-<br />
| ASCII<br />
| enclosure<br />
| text/plain<br />
| #ascii<br />
|-<br />
| NetCDF<br />
| enclosure<br />
| application/x-netcdf<br />
| #netcdf<br />
|}<br />
</blockquote><br />
<!-- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URL>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value of the ''href'' attribute is dereferenced. The ''rel'' attribute value will be ''enclosure'' or ''describedby''. The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
<br />
=== Examples ===<br />
;Access to the raw file; no OPeNDAP server involved: <link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
;The DAP2 service endpoint: <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
;The DAP2 server's HTML Form interface for this file: <link rel="describedby" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="application/rdf+xmll" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:arcrole="#html" xlink:type="simple"/><br />
<br />
;The RDF response from the DAP2 server: <link rel="describedby" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="text/html" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:arcrole="#rdf" xlink:type="simple"/><br />
<br />
;The ASCII response from the DAP2 server: <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:arcrole="#ascii" xlink:type="simple"/><br />
<br />
;The netCDF response from the DAP2 server: <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="application/x-netcdf" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:arcrole="#netcdf" xlink:type="simple"/><br />
<br />
Notes:<br />
# [[User:JamesGallagher|JamesGallagher]] 13:33, 18 March 2012 (MDT): Added the ''xlink:arcrole'' idea. I think it's very useful to make disambiguating the different response types as easy as possible. Inferring the return type using a combination of ''rel'' and ''type'' is two tests, not one and won't actually work in the case of the ''HTML form'' and ''info'' responses.<br />
# [[User:JamesGallagher|JamesGallagher]] 16:35, 14 February 2012 (MST): Updated to include the Atom 1.1 ''type'' attribute as per Pedro's suggestion.<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
# [[User:JamesGallagher|JamesGallagher]] 20:59, 13 March 2012 (MDT) At today's meeting, we referred to the ''DDX'' response as part of DAP2. It's not actually in the specification that was approved by NASA. I think we should list it with the 'commonly provided' group of responses.<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 of http://www.w3.org/TR/xlink11/ shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="text/xml"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38718DCP-42012-03-14T02:59:10Z<p>JamesGallagher: /* Proposed Solution */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset. For this the atom 1.1 ''length'' attribute should be included and its value should be the size of the file in bytes.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URL (dereferenceable)>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# For the OPeNDAP case, the only required ''link'' element is the service endpoint as described in the preceding item.<br />
# It is assumes that every valid OPeNDAP server that implements DAP2 (and the DAP2 implementation is indicated using the ''xlink:role'' attribute) will provide the following response types which do not need to be enumerated. Any DAP2-capable client will know how to access these responses:<br />
#* DAS<br />
#* DDS<br />
#* DODS (this is the 'data' response)<br />
# The following responses are not part of the DAP2 specification but are commonly provided; When they are present and a provider wants to make sure clients know they can be accessed, The ''link'' element will use the following ''rel'' and ''type'' attribute values:<br />
#* HTML, info: rel="describedby", type="text/html"<br />
#* DDX: rel="describedby", type="application/xml" (see note below)<br />
#* RDF: rel="describedby", type="application/rdf+xml"<br />
#* ASCII: rel="enclosure", type="text/plain"<br />
#* NetCDF: rel="enclosure", type="application/x-netcdf"<br />
<!-- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URL>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value of the ''href'' attribute is dereferenced. The ''rel'' attribute value will be ''enclosure'' or ''describedby''. The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
<br />
=== Examples ===<br />
;Access to the raw file; no OPeNDAP server involved: <link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
;The DAP2 service endpoint: <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
;The DAP2 server's HTML Form interface for this file: <link rel="describedby" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="application/rdf+xmll" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
;The RDF response from the DAP2 server: <link rel="describedby" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="text/html" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
;The ASCII response from the DAP2 server: <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
;The netCDF response from the DAP2 server: <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.html" title="OPeNDAP HTML Form interface acces to controversial data" type="application/x-netcdf" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
Notes:<br />
# [[User:JamesGallagher|JamesGallagher]] 16:35, 14 February 2012 (MST): Updated to include the Atom 1.1 ''type'' attribute as per Pedro's suggestion.<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
# [[User:JamesGallagher|JamesGallagher]] 20:59, 13 March 2012 (MDT) At today's meeting, we referred to the ''DDX'' response as part of DAP2. It's not actually in the specification that was approved by NASA. I think we should list it with the 'commonly provided' group of responses.<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 of http://www.w3.org/TR/xlink11/ shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="text/xml"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38717DCP-42012-03-14T02:15:20Z<p>JamesGallagher: /* MIME-TYPES */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<!-- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/> --><br />
<br />
Notes:<br />
# [[User:JamesGallagher|JamesGallagher]] 16:35, 14 February 2012 (MST): Updated to include the Atom 1.1 ''type'' attribute as per Pedro's suggestion.<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 of http://www.w3.org/TR/xlink11/ shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="text/xml"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38716DCP-42012-03-14T02:14:04Z<p>JamesGallagher: /* xlink:role in atom:link */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<!-- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/> --><br />
<br />
Notes:<br />
# [[User:JamesGallagher|JamesGallagher]] 16:35, 14 February 2012 (MST): Updated to include the Atom 1.1 ''type'' attribute as per Pedro's suggestion.<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 of http://www.w3.org/TR/xlink11/ shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38700DCP-42012-03-13T20:43:29Z<p>JamesGallagher: /* Proposed Solution */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<!-- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/> --><br />
<br />
Notes:<br />
# [[User:JamesGallagher|JamesGallagher]] 16:35, 14 February 2012 (MST): Updated to include the Atom 1.1 ''type'' attribute as per Pedro's suggestion.<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38698DCP-42012-03-13T20:33:37Z<p>JamesGallagher: /* Examples */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/dap/dap2.xsd" xlink:type="simple"/><br />
<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/> --><br />
<br />
Notes:<br />
# [[User:JamesGallagher|JamesGallagher]] 16:35, 14 February 2012 (MST): Updated to include the Atom 1.1 ''type'' attribute as per Pedro's suggestion.<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38424Applications of Semantic Web for Earth Science2012-02-29T00:54:26Z<p>JamesGallagher: </p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
= Earth and Space Science Informatics Linked Open Data =<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/.<br />
<br />
<!-- I reformatted these images to fit on a page a bit better, but at the loss of the captions... ~~~<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
--><br />
<br />
[[Image:lod_browser.jpg|frameless|border|500px|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]] [[Image:esip_authors.jpg|frameless|border|500px|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
= OPeNDAP's Hyrax Data Server Provides RDF =<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''<br />
<br />
OPeNDAP's Hyrax Data Server produces RDF for each of the datasets it serves. Because the RDF response document is produced on-the-fly from the DAP2 XML representation of the dataset, this feature is available for ''any'' dataset served by Hyrax without any configuration by the data provider.<br />
<br />
The RDF document may be accessed using the HTML 'directory' pages produced by the server (see Figure 1.) or it may be accessed by appending the suffix ''.rdf'' to the pathname component of the dataset's URL. Example: For the [http://test.opendap.org/dap/data/nc/coads_climatology.nc.html COADS Climatology] dataset, the ''service endpoint URL'' is ''<nowiki>http://test.opendap.org/dap/data/nc/coads_climatology.nc</nowiki>'' and by appending ''.rdf'', you can access the RDF document describing that dataset: ''http://test.opendap.org/dap/data/nc/coads_climatology.nc.rdf''. In fact you can gets lots of information from the service endpoint URL by appending different suffixes like ''.ddx'' or ''.html'' (Try it, it's fun!).<br />
<br />
This RDF output is used in our experimental WCS servlet and was developed as a general mechanism to perform dataset attribute translation based on ontologies. The RDF uses the default namespace ''<nowiki>http://xml.opendap.org/ns/DAP/3.2#</nowiki>''; the schema for DAP can be found at http://xml.opendap.org/dap/dap3.2.xsd. An ontology for DAP2 can be found at: http://xml.opendap.org/ontologies/opendap-dap-3.2.owl.<br />
<br />
[[File:Hyrax 1.8 dir with rdf links.png|frameless|border|500px|Figure 1. The Hyrax data server directory page view provides a simple page that can be used to access a number of responses from the server. These can also be directly accessed by web applications.]] <br />
<!-- I don't this is needed. ~~~ [[File:Screen Shot 2012-02-28 at 5.02.04 PM.png|frameless|border|500px|Figure 2.RDF listing for the COADS Climatology dataset.]] --></div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=File:Screen_Shot_2012-02-28_at_5.02.04_PM.png&diff=38423File:Screen Shot 2012-02-28 at 5.02.04 PM.png2012-02-29T00:47:59Z<p>JamesGallagher: RDF listing for the COADS Climatology dataset.</p>
<hr />
<div>RDF listing for the COADS Climatology dataset.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38422Applications of Semantic Web for Earth Science2012-02-29T00:46:31Z<p>JamesGallagher: /* OPeNDAP's Hyrax Data Server provides RDF */</p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
= Earth and Space Science Informatics Linked Open Data =<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
= OPeNDAP's Hyrax Data Server provides RDF =<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''<br />
<br />
OPeNDAP's Hyrax Data Server produces RDF for each of the datasets it serves. Because the RDF response document is produced on-the-fly from the DAP2 XML representation of the dataset, this feature is available for ''any'' dataset served by Hyrax without any configuration by the data provider.<br />
<br />
The RDF document may be accessed using the HTML 'directory' pages produced by the server (see Figure 1.) or it may be accessed by appending the suffix ''.rdf'' to the pathname component of the dataset's URL. Example: For the [http://test.opendap.org/dap/data/nc/coads_climatology.nc.html COADS Climatology] dataset, the ''service endpoint URL'' is ''<nowiki>http://test.opendap.org/dap/data/nc/coads_climatology.nc</nowiki>'' and by appending ''.rdf'', you can access the RDF document describing that dataset: ''http://test.opendap.org/dap/data/nc/coads_climatology.nc.rdf''. In fact you can gets lots of information from the service endpoint URL by appending different suffixes like ''.ddx'' or ''.html'' (Try it, it's fun!).<br />
<br />
This RDF output is used in our experimental WCS servlet and was developed as a general mechanism to perform dataset attribute translation based on ontologies. The RDF uses the default namespace ''<nowiki>http://xml.opendap.org/ns/DAP/3.2#</nowiki>''; the schema for DAP can be found at http://xml.opendap.org/dap/dap3.2.xsd. An ontology for DAP2 can be found at: http://xml.opendap.org/ontologies/opendap-dap-3.2.owl.<br />
<br />
[[File:Hyrax 1.8 dir with rdf links.png|frameless|border|300px|Figure 1. The Hyrax data server directory page view provides a simple page that can be used to access a number of responses from the server. These can also be directly accessed by web applications.]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38421Applications of Semantic Web for Earth Science2012-02-29T00:38:37Z<p>JamesGallagher: /* OPeNDAP's Hyrax Data Server provides RDF */</p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
= Earth and Space Science Informatics Linked Open Data =<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
= OPeNDAP's Hyrax Data Server provides RDF =<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''<br />
<br />
OPeNDAP's Hyrax Data Server produces RDF for each of the datasets it serves. Because the RDF response document is produced on-the-fly from the DAP2 XML representation of the dataset, this feature is available for ''any'' dataset served by Hyrax without any configuration by the data provider.<br />
<br />
The RDF document may be accessed using the HTML 'directory' pages produced by the server (see Figure 1.) or it may be accessed by appending the suffix ''.rdf'' to the pathname component of the dataset's URL. Example: For the [http://test.opendap.org/dap/data/nc/coads_climatology.nc.html COADS Climatology] dataset, the ''service endpoint URL'' is ''<nowiki>http://test.opendap.org/dap/data/nc/coads_climatology.nc</nowiki>'' and by appending ''.rdf'', you can access the RDF document describing that dataset: ''http://test.opendap.org/dap/data/nc/coads_climatology.nc.rdf''. In fact you can gets lots of information from the service endpoint URL by appending different suffixes like ''.ddx'' or ''.html'' (Try it, it's fun!).<br />
<br />
This RDF output is used in our experimental WCS servlet and was developed as a general mechanism to perform dataset attribute translation based on ontologies. The RDF uses the default namespace ''<nowiki>http://xml.opendap.org/ns/DAP/3.2#</nowiki>''; the schema for DAP can be found at http://xml.opendap.org/dap/dap3.2.xsd. An ontology for DAP2 can be found at: http://xml.opendap.org/ontologies/opendap-dap-3.2.owl.<br />
<br />
<gallery><br />
[[File:Hyrax 1.8 dir with rdf links.png|Figure 1. The Hyrax data server directory page view provides a simple page that can be used to access a number of responses from the server. These can also be directly accessed by web applications.]]<br />
</gallery></div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38420Applications of Semantic Web for Earth Science2012-02-29T00:36:34Z<p>JamesGallagher: /* OPeNDAP's Hyrax Data Server provides RDF */</p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
= Earth and Space Science Informatics Linked Open Data =<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
= OPeNDAP's Hyrax Data Server provides RDF =<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''<br />
<br />
OPeNDAP's Hyrax Data Server produces RDF for each of the datasets it serves. Because the RDF response document is produced on-the-fly from the DAP2 XML representation of the dataset, this feature is available for ''any'' dataset served by Hyrax without any configuration by the data provider.<br />
<br />
The RDF document may be accessed using the HTML 'directory' pages produced by the server (see Figure 1.) or it may be accessed by appending the suffix ''.rdf'' to the pathname component of the dataset's URL. Example: For the [http://test.opendap.org/dap/data/nc/coads_climatology.nc.html COADS Climatology] dataset, the ''service endpoint URL'' is ''<nowiki>http://test.opendap.org/dap/data/nc/coads_climatology.nc</nowiki>'' and by appending ''.rdf'', you can access the RDF document describing that dataset: ''http://test.opendap.org/dap/data/nc/coads_climatology.nc.rdf''. In fact you can gets lots of information from the service endpoint URL by appending different suffixes like ''.ddx'' or ''.html'' (Try it, it's fun!).<br />
<br />
This RDF output is used in our experimental WCS servlet and was developed as a general mechanism to perform dataset attribute translation based on ontologies. The RDF uses the default namespace ''<nowiki>http://xml.opendap.org/ns/DAP/3.2#</nowiki>''; the schema for DAP can be found at http://xml.opendap.org/dap/dap3.2.xsd. An ontology for DAP2 can be found at: http://xml.opendap.org/ontologies/opendap-dap-3.2.owl.<br />
<br />
[[File:Hyrax 1.8 dir with rdf links.png|frame|left|Figure 1. The Hyrax data server directory page view provides a simple page that can be used to access a number of responses from the server. These can also be directly accessed by web applications.]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=File:Hyrax_1.8_dir_with_rdf_links.png&diff=38419File:Hyrax 1.8 dir with rdf links.png2012-02-29T00:35:12Z<p>JamesGallagher: The Hyrax data server directory page view provides a simple page that can be used to access a number of responses from the server. These can also be directly accessed by web applications.</p>
<hr />
<div>The Hyrax data server directory page view provides a simple page that can be used to access a number of responses from the server. These can also be directly accessed by web applications.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38418Applications of Semantic Web for Earth Science2012-02-29T00:19:29Z<p>JamesGallagher: /* OPeNDAP's Hyrax Data Server provides RDF */</p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
= Earth and Space Science Informatics Linked Open Data =<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
= OPeNDAP's Hyrax Data Server provides RDF =<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''<br />
<br />
OPeNDAP's Hyrax Data Server produces RDF for each of the datasets it serves. Because the RDF response document is produced on-the-fly from the DAP2 XML representation of the dataset, this feature is available for ''any'' dataset served by Hyrax without any configuration by the data provider.<br />
<br />
The RDF document may be accessed using the HTML 'directory' pages produced by the server (see Figure 1.) or it may be accessed by appending the suffix ''.rdf'' to the pathname component of the dataset's URL. Example: For the [http://test.opendap.org/dap/data/nc/coads_climatology.nc.html COADS Climatology] dataset, the ''service endpoint URL'' is ''<nowiki>http://test.opendap.org/dap/data/nc/coads_climatology.nc</nowiki>'' and by appending ''.rdf'', you can access the RDF document describing that dataset: ''http://test.opendap.org/dap/data/nc/coads_climatology.nc.rdf''. In fact you can gets lots of information from the service endpoint URL by appending different suffixes like ''.ddx'' or ''.html'' (Try it, it's fun!).<br />
<br />
This RDF output is used in our experimental WCS servlet and was developed as a general mechanism to perform dataset attribute translation based on ontologies. The RDF uses the default namespace ''<nowiki>http://xml.opendap.org/ns/DAP/3.2#</nowiki>''; the schema for DAP can be found at http://xml.opendap.org/dap/dap3.2.xsd. An ontology for DAP2 can be found at: http://xml.opendap.org/ontologies/opendap-dap-3.2.owl.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38417Applications of Semantic Web for Earth Science2012-02-28T23:40:21Z<p>JamesGallagher: /* OPeNDAP's Hyrax Data Server provides RDF */</p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
= Earth and Space Science Informatics Linked Open Data =<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
= OPeNDAP's Hyrax Data Server provides RDF =<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''<br />
<br />
OPeNDAP's Hyrax Data Server produces RDF for each of the datasets it serves. The RDF response document is produced on-the-fly from the DAP2 XML representation of the dataset.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38416Applications of Semantic Web for Earth Science2012-02-28T23:09:09Z<p>JamesGallagher: </p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
= Earth and Space Science Informatics Linked Open Data =<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
= OPeNDAP's Hyrax Data Server provides RDF =<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Applications_of_Semantic_Web_for_Earth_Science&diff=38415Applications of Semantic Web for Earth Science2012-02-28T22:45:47Z<p>JamesGallagher: /* Data Quality Screening Service */</p>
<hr />
<div>= Introduction =<br />
Semantic web technology is becoming ever more important in Earth Science applications in a number of diverse roles. Furthermore, it is likely to become an even more important enabler as ambitious data science efforts, such as the Earth Cube initiative and ESIP's own Earth Science Collaboratory, more forward. These enterprises seek to make it easier to bring disparate datasets together as well as disparate disciplines and even communities in an effort to leverage our burgeoning data in the service of understanding the Earth as a system. As these various resources and the communities leveraging them diversify, the need for semantic technology to help users navigate the sea of resources becomes more apparent. Indeed, this role in discovery is acknowledged in the key capabilities determined through the first EarthCube Charrette.<br />
<br />
However, we should not neglect the important role semantic technology can and does play in other aspects of data for Earth Sciences. For instance, semantic technology can be found in a key role in several other areas noted in the Earth Cube charrette capabilities:<br />
* Automated Quality Assurance and Quality Control<br />
* Provenance capture and interpretation<br />
* Workflow construction<br />
* Data fusion<br />
<br />
Many such applications use underpinned by semantic technology, with the result that its value is not always readily apparent. In this short white paper, we discuss several ongoing or completed projects and applications that use semantic web as an underpinning in order to raise awareness of this critical technology.<br />
<br />
= Data Quality Screening Service =<br />
''by Christopher Lynnes, NASA/GSFC''<br />
<br />
The Data Quality Screening Service (DQSS) is designed to help automate the filtering of remote sensing data on behalf of science users. Whereas this process today involves much research through quality documents, followed by laborious coding, the DQSS acts as a Web Service to provide data users with data pre-filtered to their particular criteria, while at the same time guiding the user with filtering recommendations of the cognizant data experts. Data that do not pass the criteria are replaced with fill values, resulting in a file that has the same structure and is usable in the same ways as the original (Fig. 1).<br />
[[Image:Dqss_ike.gif|frame|Fig.1. Data Quality Screening Service showing a data array before screening, the quality criteria mask used for screening and the data array after screening. The scene is for Total Precipitable Water over Hurricane Ike on 9 September 2008. The figure on the left shows anomalously dry areas on the east side of the hurricane; however, these turn out to be low quality retrievals (center) and thus are removed from the data array by the screening process.]]<br />
<br />
At the core of DQSS is an ontology that describes data fields, the quality fields for applying quality control and the interpretations of quality criteria. This allows a generalized code base that can nonetheless handle both a variety of datasets and a variety of quality control schemes. Indeed, a data collection can be added to the DQSS simply by registering instances in the ontology if it follows a quality scheme that is already modeled in the ontology. This will allow DQSS to scale to more data products with minimal cost.<br />
<br />
For more on DQSS, see http://disc.sci.gsfc.nasa.gov/services/data-quality-screening-service.<br />
<br />
== Earth and Space Science Informatics Linked Open Data ==<br />
''by Tom Narock (University of Maryland, Baltimore County) and Eric Rozell (Rensselaer Polytechnic Institute)''<br />
<br />
<br />
Linked Open Data (LOD) is a data publishing methodology comprised of four simple principles.<br />
* Use unique identifiers (URIs) as names <br />
* Make those identifiers dereferenceable via HTTP<br />
* Dereferencing an identifier should return RDF (the data representation language of the semantic web)<br />
* Include links to other data sets<br />
Following these principles results in structured data with explicit semantics. As a result, data from different sources can be connected and queried. Earth and Space Science Informatics Linked Open Data (ESSI-LOD) is a project aimed at creating Linked Open Data within the Earth and Space Sciences. Initial data sets to this<br />
project include historical conference data from the American Geophysical Union (AGU) as well as membership and meeting data from the Federation of Earth Science Information Partners (ESIP). Many members of the Earth science community participate in both AGU and ESIP, and there are many implicit relationships between the groups. However, answering questions across the two organizations has been difficult due to data being stored in proprietary and non-interoperable formats.<br />
<br />
ESSI-LOD created Linked Open Data to alleviate these limitations. We converted 7 years of AGU conference data (2005-2010)and 5 years of ESIP membership/meeting data (2007-2011) into RDF and exposed it as Linked Open Data. Links between the data sets were made at the person level where we identified identities between AGU authors and ESIP members. Exposing LOD has opened the data to cross-organizational question answering, collaboration discovery, analysis of trends, and insight into the underlying social network. Moreover, LOD is scalable and easily affords other organizations the ability to link their LOD data to ESSI-LOD - thus further extending data fusion and querying capabilities.<br />
<br />
The benefits of ESSI-LOD have been enabled by simple semantic web principles and reusable vocabularies. These semantic web technologies have facilitated rapid browsing (Figure 1), querying, visualizing (Figure 2), and extensibility not easily obtainable with the original data sets.<br />
<br />
For more information on ESSI-LOD visit: http://essi-lod.org/<br />
[[Image:lod_browser.jpg|frame|Fig.1. A web interface to ESSI-LOD. This tool is based on open source software and allows browsing of the linked data. Session, Authors, and Keywords are all links and allow users to interactively explore the linked data graph.]]<br />
<br />
[[Image:esip_authors.jpg|frame|Fig.2. A visualization of ESSI-LOD data showing the co-authorship network of ESIP members who have attended AGU conferences. Each node represents an author and edges indicate co-authorship on an AGU conference presentation. The visualization illustrates cross-organizational querying by limiting the AGU authors to only those who are also ESIP members.]]<br />
<br />
== OPeNDAP's Hyrax Data Server provides RDF ==<br />
''by James Gallagher and Nathan Potter, OPeNDAP, Inc.''</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38292DCP-42012-02-14T23:35:05Z<p>JamesGallagher: /* Examples */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# [[User:JamesGallagher|JamesGallagher]] 16:35, 14 February 2012 (MST): Updated to include the Atom 1.1 ''type'' attribute as per Pedro's suggestion.<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38291DCP-42012-02-14T23:33:17Z<p>JamesGallagher: /* xlink:role in atom:link */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38290DCP-42012-02-14T23:32:56Z<p>JamesGallagher: /* xlink:role in atom:link */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
[[User:JamesGallagher|JamesGallagher]] 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of ''xlink:type''; it's a minor point because when xlink:type is ''simple'' all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 shows the supported collections of attributes depending on the value of xlink:type.<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38289DCP-42012-02-14T23:26:18Z<p>JamesGallagher: /* Examples */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38288DCP-42012-02-14T23:24:48Z<p>JamesGallagher: /* Discussions */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
=== Notes (Pedro) ===<br />
<br />
==== xlink:role in atom:link ====<br />
<br />
from the information in <br />
<br />
http://www.w3.org/TR/xlink11/#att-method<br />
<br />
it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element<br />
<br />
==== MIME-TYPES ====<br />
In your examples we are missing the type attribute that gives us the mime-type of the resource <br />
<br />
[[User:JamesGallagher|JamesGallagher]] 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from ''application/x-hdf5''<br />
<br />
So the examples would be:<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/><br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=Discovery_Change_Proposals&diff=38266Discovery Change Proposals2012-02-14T17:14:57Z<p>JamesGallagher: /* Current Change Proposals */</p>
<hr />
<div>[[Discovery_Governance|<< Back to the Discovery Cluster Governance page]]<br />
<br />
== Current Change Proposals ==<br />
<br />
=== [[Discovery Change Proposal-1 | DCP-1: ESIP Discovery Cast Atom Response Format v1.1]] ===<br />
* '''Submitted on''': 2011-02-08T13:00 PST<br />
* '''Ratified on''': 2011-03-22T12:30 PST<br />
=== [[Discovery Change Proposal-2 | DCP-2: Canonicalizing Granule-level OPeNDAP Links]] ===<br />
* '''Submitted on''': 2011-06-15<br />
=== [[Discovery Change Proposal-3 | DCP-3: Standardized Linking from one cast to another or to additional metadata]] ===<br />
* '''Submitted on''': 2011-10-10<br />
=== [[DCP-4 | DCP-4: OPeNDAP Links in the Atom <link/> element]] ===<br />
* '''Submitted on''': 2012-02-14<br />
<br />
== How to add new change proposal? ==<br />
<br />
* Editors, please use this [[Discovery Change Proposal Template]].<br />
<br />
== Incubation Ideas ==<br />
<br />
* Specific extensions to Discovery Atom Response format for Granule-level, Collection-level, and Service responses. Simply builds upon DCP-1.<br />
* Discovery RSS Response Format?<br />
* OpenSearch Request Format. adopt OGC OpenSearch spec?<br />
* ServiceCasting Request Format?<br />
* DataCasting Request Format?<br />
* Mashup conventions?<br />
* [http://wiki.apache.org/solr/CommonQueryParameters Apache SOLR Request format]<br />
* [http://wiki.apache.org/solr/QueryResponseWriter Apache SOLR Response format]<br />
* [http://wiki.apache.org/nutch/FAQ#What_is_the_RSS_symbol_in_search_results_all_about.3F Apache Nutch Opensearch RSS response format]<br />
* [[Custom Elements]]<br />
* [[OPeNDAP Link Type]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38265DCP-42012-02-14T17:12:30Z<p>JamesGallagher: /* DCP-4: OPeNDAP Links in the Atom element */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[User:JamesGallagher|JamesGallagher]]<br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38264DCP-42012-02-14T17:12:09Z<p>JamesGallagher: /* DCP-4: OPeNDAP Links in the Atom element */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': 14 Feb 2012<br />
# '''Review period''': 14 Feb 2012 to 14 March 2012<br />
# '''Revision''': N/A<br />
# '''Vote''': TBD<br />
# '''Final review''': TBD<br />
# '''Ratified''': TBD<br />
# '''Rejected''': TBD<br />
* '''Facilitator''': [[JamesGallagher]] <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38263DCP-42012-02-14T17:07:06Z<p>JamesGallagher: /* Examples */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-7&diff=38262DCP-72012-02-14T17:01:16Z<p>JamesGallagher: moved DCP-7 to DCP-4: Hosed name... Didn't realized '4' was left open for this.</p>
<hr />
<div>#REDIRECT [[DCP-4]]</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38261DCP-42012-02-14T17:01:16Z<p>JamesGallagher: moved DCP-7 to DCP-4: Hosed name... Didn't realized '4' was left open for this.</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data proving controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38260DCP-42012-02-14T16:59:55Z<p>JamesGallagher: /* DCP-7: OPeNDAP Links in the Atom element */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-4: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data proving controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38252DCP-42012-02-14T01:12:42Z<p>JamesGallagher: /* Discussions */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data proving controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-qualified ''href'' attribute and the ''Atom 1.1'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. Note that ''xlink:href'' is not required for ''xlink:type="simple"''. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38251DCP-42012-02-14T01:11:19Z<p>JamesGallagher: /* Examples */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data proving controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. I note that xlink:href is not required for xlink:type = simple. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38250DCP-42012-02-14T01:04:25Z<p>JamesGallagher: /* Proposed Solution */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
<! -- # A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response. --><br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
=== Examples ===<br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data proving controversial things"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/><br />
<br />
<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/><br />
<br />
<!-- <link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of confrontation" xlink:role="http://xml.opendap.org/DAP2#" xlink:arcrole=".ddx" xlink:type="simple"/> --><br />
<br />
Notes:<br />
# The ''xlink:type="simple"'' is not needed; if ''xlink:type'' is not present it defaults to ''simple''<br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. I note that xlink:href is not required for xlink:type = simple. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38249DCP-42012-02-14T00:50:32Z<p>JamesGallagher: /* Discussions */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response.<br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. I note that xlink:href is not required for xlink:type = simple. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38248DCP-42012-02-14T00:49:23Z<p>JamesGallagher: /* Discussions */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response.<br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The Atom 1.1 ''title'' attribute is used rather than ''xlink:title'' because feed readers are more likely to display it, I believe.<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome. I note that xlink:href is not required for xlink:type = simple. <br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38247DCP-42012-02-14T00:47:20Z<p>JamesGallagher: /* Rationale for the Solution */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response.<br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome.<br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38246DCP-42012-02-14T00:46:25Z<p>JamesGallagher: /* Proposed Solution */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''title="<<some human readable title that mentions OPeNDAP>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''". The ''title'' will contain some human readable text that mentions both OPeNDAP and the specific response.<br />
# Stamp and Repeat for WCS, other protocols.<br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will behave in a way that is at least not toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome.<br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38245DCP-42012-02-14T00:43:08Z<p>JamesGallagher: /* Proposed Solution */</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the Atom 1.1 ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:title="<<some human readable title>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'', ''xlink:title="<<some human readable title>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''"<br />
# Repeat for WCS<br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will behave in a way that is at least not toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome.<br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagherhttps://wiki.esipfed.org/w/index.php?title=DCP-4&diff=38244DCP-42012-02-14T00:42:15Z<p>JamesGallagher: Created page with "<< Back to the Discovery Change Proposals page = DCP-7: OPeNDAP Links in the Atom <link/> element = * '''Progress''' (fill in the dates as the p..."</p>
<hr />
<div>[[Discovery_Change_Proposals|<< Back to the Discovery Change Proposals page]]<br />
<br />
<br />
= DCP-7: OPeNDAP Links in the Atom <link/> element =<br />
<br />
* '''Progress''' (fill in the dates as the process moves forward)<br />
# '''Submitted on''': when the DCP was submitted<br />
# '''Review period''': the review period<br />
# '''Revision''': when revisions are being made based on feedback<br />
# '''Vote''': the voting period<br />
# '''Final review''': when final adjustments are being made and final review<br />
# '''Ratified''': when approved.<br />
# '''Rejected''': or when rejected.<br />
* '''Facilitator''': the primary editor to help the DCP move along the process. <br />
<br />
== Description ==<br />
<br />
To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).<br />
<br />
== Problem Addressed ==<br />
<br />
We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL. <br />
<br />
== Proposed Solution ==<br />
<br />
Include multiple ''<link href=.../>'' elements for each dataset to be cast. Different <link/> elements can be categorized as follows:<br />
# A <link/> with only the ''href'', ''title'' and ''rel'' attributes will be interpreted to reference the 'raw' dataset.<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'' and ''xlink:title="<<some human readable title>>"'' will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the ''href'' attribute and the ''rel'' attribute will be ''"enclosure''"<br />
# A <link/> with the attributes ''xlink:type="simple"'' with the additional attributes ''xlink:role="<<dap schema URI>>"'', ''xlink:title="<<some human readable title>>"'' and ''xlink:arcrole="<<DAP suffix>>"'' will be interpreted to reference a DAP response object using an endpoint. The ''arcrole'' will denote exactly which response will be returned when the URL that is the value ofthe ''href'' attribute is dereferenced. The ''rel'' attribute will be ''"enclosure''"<br />
# Repeat for WCS<br />
<br />
== Rationale for the Solution ==<br />
<br />
Xlink is the best way to include arbitrary metadata about a link ''in'' a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will behave in a way that is at least not toxic to users.<br />
<br />
== Discussions ==<br />
<br />
The fact that ''xlink'' includes a namespace-escape ''href'' attribute and the ''Atom'' specification requires that ''href'' be present in ''<link/>'' elements is cumbersome.<br />
<br />
NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.<br />
<br />
== Consensus ==<br />
<br />
Voting results.</div>JamesGallagher