[Esip-documentation] [esip-semantictech] ACDD vocab as RDF
John Graybeal
jbgraybeal at mindspring.com
Sun Dec 2 00:00:38 EST 2018
Thanks for the clarification Jim! While it seems like NUG and CF might be improvable, I always assumed the changes would be difficult to achieve and too subtle to invest the time into. They are much more widely used than ACDD and might have different motivations/applications, once different generality.
On the other hand, giving all their terms proper IRIs might be within reach, we even have a start in the case of CF. :-)
John
> On Nov 30, 2018, at 9:53 AM, Jim Biard via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
>
> John,
>
> I may have been unclear. I was trying to suggest that it would be good for the parent/ancestor conventions to update their definitions so that ACDD didn't have to improve them, not to imply that ACDD was sloppy. If that's not an option, then ACDD doesn't have much choice.
>
> Grace and peace,
>
> Jim
> On 11/30/18 1:24 AM, John Graybeal wrote:
>> Jim,
>>
>> Umm, not to be *too* defensive I hope, but ACDD was trying to be particularly precise to improve what were often very casually specified attributes. Of course, I have found that perfect precision is pretty tough in real-world specifications, and I expect there are a few things (*ahem*) that could be improved. (And I should note that for many attributes, a much more precise version was explicitly opposed by current real-world users, who saw a lot of work for not enough benefit.)
>>
>> Still, if you think ACDD was being sloppy in any of these specifications, please bring up the specifics so that the next go-round can perhaps fix them. Thanks.
>>
>> John
>>
>>
>>> On Nov 27, 2018, at 12:48, Jim Biard via Esip-documentation <esip-documentation at lists.esipfed.org <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>>
>>> Hi.
>>>
>>> I'm not strong on the subtleties of skos:broader and all that, but I definitely agree that the Conventions attribute (for example) is a basic NUG-level concept and attribute name. The concept is a list of the conventions being followed in the netCDF file. The current documentation for NUG, CF, and ACDD may make a bit of a mess of that because they weren't trying to be precise in that way (and may have been sloppy). It seems to me that the best solution for all the overlapping attributes is to improve the original owning convention to be more precise. Refactoring - handing ownership back to the appropriate convention while improving the definition - is likely better than duplication.
>>>
>>> Grace and peace,
>>>
>>> Jim
>>> On 11/22/18 12:28 PM, John Graybeal via Esip-documentation wrote:
>>>> Yeah, this is subtle. It is true that title and Conventions (and others) are re-used in ACDD, and the description in ACDD is rarely identical to the original. If I am not mistaken, in all cases the difference reflects additional guidance for ACDD users (e.g., the Conventions instructions say to add the ACDD 1.3 string for ACDD-conformant metadata), but never overrides. So people who follow the ACDD conventions may use the attributes in a particular way, but their use will still be consistent with NUG and CF definitions, by design of ACDD. (And ACDD does not present any conflicts with those other conventions.)
>>>>
>>>> So, which do you say? “It’s the same attribute as NUG/CF, so use the original identifier.” (As if one exists. :->) Or, “We’re adding our own special sauce, so that makes it a new concept, give it a new identifier."
>>>>
>>>> I think this is one of those ‘no perfect answer’ questions. If I were making a reasonably faithful representation of ACDD, I would give these reused attributes new concept names, and declare their relation to the originals (e.g., ACDD:attribute skos:broader NUG:attribute), to show ours is a narrower application but still conforms to the originals. (I’m not claiming SKOS term relations are the best solution in this particular case.)
>>>>
>>>> I expect others might choose to make it all ACDD attributes without reference to the parent, or to make them reuse the parent attribute whenever one exists. (The latter for the same reason we recommended option 2: it increases interoperability when everyone uses the same broad term.) For me, the deciding point is that we customized the guidance for almost every one in the standard, so a new concept related to the original is more precise. Only: exceptions might be title, Conventions, and comment.
>>>>
>>>> But I’m a splitter, not a lumper, and I don’t much like everyone using totally generic attributes like dc:type when those definition is often highly non-interoperable. ("The nature or genre of the content of the resource…”)
>>>>
>>>> Like I said, no one right answer.
>>>>
>>>> John
>>>>
>>>>
>>>> ---------------------------------------
>>>> John Graybeal
>>>> jbgraybeal at mindspring.com <mailto:jbgraybeal at mindspring.com>
>>>> 650-450-1853
>>>> skype: graybealski
>>>> linkedin: http://www.linkedin.com/in/johngraybeal/ <http://www.linkedin.com/in/johngraybeal/>
>>>>
>>>>> On Nov 13, 2018, at 09:39, Armstrong, Edward M (398G) via Esip-documentation <esip-documentation at lists.esipfed.org <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I’m fine with going with option 2 to clearly separate different vocabularies from NUG, CF and ACDD. But there is still the problem of how to best document overlap…. I believe there was a little misinformation earlier in the thread. For example, attributes “title”, and “Conventions” are clearly and uniquely defined and assigned in ACDD and CF even if they have the same language. For example see here:
>>>>>
>>>>> http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-3 <http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-3> (look for Highly Recommended Global Attributes)
>>>>>
>>>>> From: Ethan Davis <edavis at ucar.edu <mailto:edavis at ucar.edu>>
>>>>> Date: Monday, November 12, 2018 at 1:09 PM
>>>>> To: Jonathan Yu <Jonathan.Yu at csiro.au <mailto:Jonathan.Yu at csiro.au>>
>>>>> Cc: Nan Galbraith <ngalbraith at whoi.edu <mailto:ngalbraith at whoi.edu>>, "Armstrong, Edward M (398G)" <Edward.M.Armstrong at jpl.nasa.gov <mailto:Edward.M.Armstrong at jpl.nasa.gov>>, David Neufeld <david.neufeld at noaa.gov <mailto:david.neufeld at noaa.gov>>, "esip-documentation at lists.esipfed.org <mailto:esip-documentation at lists.esipfed.org>" <esip-documentation at lists.esipfed.org <mailto:esip-documentation at lists.esipfed.org>>, "dev at sis.apache.org <mailto:dev at sis.apache.org>" <dev at sis.apache.org <mailto:dev at sis.apache.org>>, "Hedley, Mark" <mark.hedley at metoffice.gov.uk <mailto:mark.hedley at metoffice.gov.uk>>, Adam Leadbetter <Adam.Leadbetter at marine.ie <mailto:Adam.Leadbetter at marine.ie>>, Jim Biard <jim.biard at noaa.gov <mailto:jim.biard at noaa.gov>>, Aleksandar Jelenak <ajelenak at hdfgroup.org <mailto:ajelenak at hdfgroup.org>>
>>>>> Subject: Re: [Esip-documentation] Fwd: [esip-semantictech] ACDD vocab as RDF
>>>>>
>>>>> Hi Jonathan, all,
>>>>>
>>>>> Yes, Unidata could host something to capture the list of attributes included in NUG. We've started looking at making the NUG a bit more standalone (less intertwined with the C library docs). This might fit right in with that effort.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Ethan
>>>>>
>>>>> On Wed, Nov 7, 2018 at 4:56 PM <Jonathan.Yu at csiro.au <mailto:Jonathan.Yu at csiro.au>> wrote:
>>>>>> Hi Dave, Edward, and Nan,
>>>>>>
>>>>>> Thanks for that. Also, capturing semantics about global vs. variable level properties would be good too.
>>>>>>
>>>>>> On representing properties... It would be ideal if we had CF, NUG and ACDD properties represented too. We're in a bootstrapping phase at the moment - these do not yet exist for the 3 conventions. The issue also is around publishing resources that are governed by the respective communities. I wonder if I could ask which of the following options is preferable for capturing attributes used across CF, ACDD and the NetCDF user's guide - (where <=> is something like a sameAs or exactMatch relationship) ?
>>>>>>
>>>>>> -Option 1: Include equivalence statements across communities-
>>>>>> acdd:title <=> cf:title <=> nug:title
>>>>>> acdd:Conventions <=> cf:Conventions <=> nug:Conventions
>>>>>>
>>>>>> or
>>>>>>
>>>>>> -Option 2: Publish -
>>>>>> nug:title
>>>>>> nug:Conventions
>>>>>>
>>>>>> @Ethan - would Unidata consider hosting a Github repo with a CSV or RDF files for capturing the list of attributes included in the NUG? The ESIP COR might be an option for hosting Linked Data descriptions for them like http://cor.esipfed.org/ont/~jyu/test-acdd <http://cor.esipfed.org/ont/~jyu/test-acdd>
>>>>>>
>>>>>> Regards,
>>>>>> Jonathan
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Nan Galbraith [mailto:ngalbraith at whoi.edu <mailto:ngalbraith at whoi.edu>]
>>>>>> Sent: Tuesday, 6 November 2018 7:00 AM
>>>>>> To: Armstrong, Edward M (398G) <Edward.M.Armstrong at jpl.nasa.gov <mailto:Edward.M.Armstrong at jpl.nasa.gov>>; David Neufeld <david.neufeld at noaa.gov <mailto:david.neufeld at noaa.gov>>; Cluster Documentation <esip-documentation at lists.esipfed.org <mailto:esip-documentation at lists.esipfed.org>>; dev at sis.apache.org <mailto:dev at sis.apache.org>
>>>>>> Cc: Yu, Jonathan (L&W, Clayton) <Jonathan.Yu at csiro.au <mailto:Jonathan.Yu at csiro.au>>
>>>>>> Subject: Re: [Esip-documentation] Fwd: [esip-semantictech] ACDD vocab as RDF
>>>>>>
>>>>>> I'd like to clarify that we have printed some attributes in our documentation (e.g. title, source, Conventions) that are not just identical to CF or NUG, but actually belong to those conventions, not to ACDD. The text may not be quite as explicit as it was at one point, but we defer to CF or NUG for these definitions, and don't claim ownership of them. They're included in our documentation because they're such a necessary part of discovery.
>>>>>>
>>>>>> At least that's my take on this.
>>>>>>
>>>>>> Cheers - Nan
>>>>>>
>>>>>>
>>>>>> On 11/5/18 12:22 PM, Armstrong, Edward M (398G) via Esip-documentation
>>>>>> wrote:
>>>>>> >
>>>>>> > Hello:
>>>>>> >
>>>>>> > What about combining this or integrating this with CF in some manner ?
>>>>>> > Some of the attributes like “title” and “source” are exactly the same.
>>>>>> >
>>>>>> > Be careful of mixing global vs variables attributes. For example
>>>>>> > ‘*coverage_content_type*’ was on the list (but not units or long_name
>>>>>> > etc.)
>>>>>> >
>>>>>> > I recommend you look at variable attributes but they have to be
>>>>>> > treated separately.
>>>>>> >
>>>>>> > *From: *Esip-documentation
>>>>>> > <esip-documentation-bounces at lists.esipfed.org <mailto:esip-documentation-bounces at lists.esipfed.org>> on behalf of David
>>>>>> > Neufeld via Esip-documentation <esip-documentation at lists.esipfed.org <mailto:esip-documentation at lists.esipfed.org>>
>>>>>> > *Reply-To: *David Neufeld <david.neufeld at noaa.gov <mailto:david.neufeld at noaa.gov>>
>>>>>> > *Date: *Monday, November 5, 2018 at 8:36 AM
>>>>>> > *To: *Cluster Documentation <esip-documentation at lists.esipfed.org <mailto:esip-documentation at lists.esipfed.org>>,
>>>>>> > "dev at sis.apache.org <mailto:dev at sis.apache.org>" <dev at sis.apache.org <mailto:dev at sis.apache.org>>
>>>>>> > *Cc: *Jonathan Yu <jonathan.yu at csiro.au <mailto:jonathan.yu at csiro.au>>
>>>>>> > *Subject: *[Esip-documentation] Fwd: [esip-semantictech] ACDD vocab as
>>>>>> > RDF
>>>>>> >
>>>>>> > Hi All,
>>>>>> >
>>>>>> > Just sharing this across some other communities as interest in a
>>>>>> > machine readable format has been expressed previously for ACDD.
>>>>>> >
>>>>>> > Note there's a JSON-LD representation as well at the test repo link.
>>>>>> >
>>>>>> > Thanks Jonathan!
>>>>>> >
>>>>>> > Dave
>>>>>> >
>>>>>> > ---------- Forwarded message ---------
>>>>>> > From: *Jonathan Yu via esip-semanticweb*
>>>>>> > <esip-semanticweb at lists.esipfed.org <mailto:esip-semanticweb at lists.esipfed.org>
>>>>>> > <mailto:esip-semanticweb at lists.esipfed.org <mailto:esip-semanticweb at lists.esipfed.org>>>
>>>>>> > Date: Sun, Nov 4, 2018 at 7:38 PM
>>>>>> > Subject: [esip-semantictech] ACDD vocab as RDF
>>>>>> > To: <esip-semanticweb at lists.esipfed.org <mailto:esip-semanticweb at lists.esipfed.org>
>>>>>> > <mailto:esip-semanticweb at lists.esipfed.org <mailto:esip-semanticweb at lists.esipfed.org>>>
>>>>>> > Cc: <mark.hedley at metoffice.gov.uk <mailto:mark.hedley at metoffice.gov.uk>
>>>>>> > <mailto:mark.hedley at metoffice.gov.uk <mailto:mark.hedley at metoffice.gov.uk>>>, <ajelenak at hdfgroup.org <mailto:ajelenak at hdfgroup.org>
>>>>>> > <mailto:ajelenak at hdfgroup.org <mailto:ajelenak at hdfgroup.org>>>, <Adam.Leadbetter at marine.ie <mailto:Adam.Leadbetter at marine.ie>
>>>>>> > <mailto:Adam.Leadbetter at marine.ie <mailto:Adam.Leadbetter at marine.ie>>>
>>>>>> >
>>>>>> > Hi all,
>>>>>> >
>>>>>> > I’ve been observing the list for a while, but today have something to
>>>>>> > share that might be of interest to this mailing list.
>>>>>> >
>>>>>> > I’m part of a working group developing a netCDF Linked Data
>>>>>> > (netCDF-LD) standard with tools over at
>>>>>> > https://binary-array-ld.github.io/netcdf-ld/ <https://binary-array-ld.github.io/netcdf-ld/>
>>>>>> >
>>>>>> > As part of this work, we’ve identified an opportunity for the ACDD
>>>>>> > vocabulary to be ‘triplified’ with stable identifiers hosted by ESIP.
>>>>>> > This would greatly help our efforts in providing a translation pathway
>>>>>> > from netCDF files (using ACDD and CF) into RDF and RDF
>>>>>> > profiles/flavours (like schema.org <http://schema.org/> <http://schema.org <http://schema.org/>>). This might
>>>>>> > hook into some of the discussion about schema.org <http://schema.org/> <http://schema.org <http://schema.org/>>
>>>>>> > and future work by ESIP Sem Web…
>>>>>> >
>>>>>> > To this end, I’d like to share some initial work to turn the ACDD
>>>>>> > convention documented at
>>>>>> > (http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Disco <http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Disco>
>>>>>> > very_1-3)
>>>>>> > into CSV.
>>>>>> >
>>>>>> > This is being developed over at https://github.com/ESIPFed/acdd <https://github.com/ESIPFed/acdd> (see
>>>>>> > PR https://github.com/ESIPFed/acdd/pull/2 <https://github.com/ESIPFed/acdd/pull/2>).
>>>>>> >
>>>>>> > The aim is to eventually publish through the COR. I have a test repo
>>>>>> > at http://cor.esipfed.org/ont/~jyu/test-acdd <http://cor.esipfed.org/ont/~jyu/test-acdd>
>>>>>> > <http://cor.esipfed.org/ont/%7Ejyu/test-acdd <http://cor.esipfed.org/ont/%7Ejyu/test-acdd>> .
>>>>>> >
>>>>>> > We’d appreciate any feedback or contributions to this work. An
>>>>>> > ambitious target would be to have this stabilised by Christmas :)
>>>>>> >
>>>>>> > Regards,
>>>>>> >
>>>>>> > Jonathan
>>>>>> >
>>>>>> > p.s. if you’re interested, see
>>>>>> > https://github.com/binary-array-ld/bald/wiki/Schema.org-mappings <https://github.com/binary-array-ld/bald/wiki/Schema.org-mappings> for
>>>>>> > an initial schema.org <http://schema.org/> <http://schema.org <http://schema.org/>> mapping.
>>>>>> >
>>>>>> > *Jonathan Yu*
>>>>>> >
>>>>>> > Senior Experimental Scientist | Data Scientist
>>>>>> >
>>>>>> > Environmental Informatics <https://research.csiro.au/ei <https://research.csiro.au/ei>> | Water
>>>>>> > Resources Management | Land and Water
>>>>>> >
>>>>>> > CSIRO
>>>>>> >
>>>>>> > *E*jonathan.yu at csiro.au <mailto:E*jonathan.yu at csiro.au> <mailto:jonathan.yu at csiro.au <mailto:jonathan.yu at csiro.au>> *T* +61 3 9545
>>>>>> > 2457 *M* +61 4 7773 0733
>>>>>> >
>>>>>> > Bayview Ave, Clayton VIC 3168, AUSTRALIA *|* Postal Address: Private
>>>>>> > Bag 10, Clayton South VIC 3169, AUSTRALIA
>>>>>> >
>>>>>> > www.csiro.au <http://www.csiro.au/> <http://www.csiro.au/ <http://www.csiro.au/>>
>>>>>> >
>>>>>> > ResearcherID: F-2336-2011
>>>>>> > <http://www.researcherid.com/rid/F-2336-2011 <http://www.researcherid.com/rid/F-2336-2011>> | ORCID:
>>>>>> > 0000-0002-2237-0091 <http://orcid.org/0000-0002-2237-0091 <http://orcid.org/0000-0002-2237-0091>> | Google
>>>>>> > scholar: _ikiM_EAAAAJ
>>>>>> > <https://scholar.google.com.au/citations?user=_ikiM_EAAAAJ <https://scholar.google.com.au/citations?user=_ikiM_EAAAAJ>>
>>>>>> >
>>>>>> > **
>>>>>> >
>>>>>> > *PLEASE NOTE*
>>>>>> >
>>>>>> > The information contained in this email may be confidential or
>>>>>> > privileged. Any unauthorised use or disclosure is prohibited. If you
>>>>>> > have received this email in error, please delete it immediately and
>>>>>> > notify the sender by return email. Thank you. To the extent permitted
>>>>>> > by law, CSIRO does not represent, warrant and/or guarantee that the
>>>>>> > integrity of this communication has been maintained or that the
>>>>>> > communication is free of errors, virus, interception or interference.
>>>>>> >
>>>>>> > /Please consider the environment before printing this email./
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > esip-semanticweb mailing list
>>>>>> > esip-semanticweb at lists.esipfed.org <mailto:esip-semanticweb at lists.esipfed.org>
>>>>>> > <mailto:esip-semanticweb at lists.esipfed.org <mailto:esip-semanticweb at lists.esipfed.org>>
>>>>>> > https://lists.esipfed.org/mailman/listinfo/esip-semanticweb <https://lists.esipfed.org/mailman/listinfo/esip-semanticweb>
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > David Neufeld
>>>>>> >
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *******************************************************
>>>>>> * Nan Galbraith Information Systems Specialist *
>>>>>> * Upper Ocean Processes Group Mail Stop 29 *
>>>>>> * Woods Hole Oceanographic Institution *
>>>>>> * Woods Hole, MA 02543 (508) 289-2444 *
>>>>>> *******************************************************
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Esip-documentation mailing list
>>>>> Esip-documentation at lists.esipfed.org <mailto:Esip-documentation at lists.esipfed.org>
>>>>> https://lists.esipfed.org/mailman/listinfo/esip-documentation <https://lists.esipfed.org/mailman/listinfo/esip-documentation>
>>>>
>>>>
>>>> _______________________________________________
>>>> Esip-documentation mailing list
>>>> Esip-documentation at lists.esipfed.org <mailto:Esip-documentation at lists.esipfed.org>
>>>> https://lists.esipfed.org/mailman/listinfo/esip-documentation <https://lists.esipfed.org/mailman/listinfo/esip-documentation>
>>> --
>>> <http://www.cicsnc.org/>Visit us on
>>> Facebook <http://www.facebook.com/cicsnc> Jim Biard
>>> Research Scholar
>>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
>>> North Carolina State University <http://ncsu.edu/>
>>> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
>>> formerly NOAA’s National Climatic Data Center
>>> 151 Patton Ave, Asheville, NC 28801
>>> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
>>> o: +1 828 271 4900
>>>
>>> Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>.
>>> _______________________________________________
>>> Esip-documentation mailing list
>>> Esip-documentation at lists.esipfed.org <mailto:Esip-documentation at lists.esipfed.org>
>>> https://lists.esipfed.org/mailman/listinfo/esip-documentation <https://lists.esipfed.org/mailman/listinfo/esip-documentation>
>>
> --
> <http://www.cicsnc.org/>Visit us on
> Facebook <http://www.facebook.com/cicsnc> Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
> formerly NOAA’s National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
> o: +1 828 271 4900
>
> Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>.
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> https://lists.esipfed.org/mailman/listinfo/esip-documentation
John Graybeal
jbgraybeal at mindspring.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-documentation/attachments/20181201/127c2206/attachment-0001.html>
More information about the Esip-documentation
mailing list