[Esip-documentation] Fwd: [esip-semantictech] ACDD vocab as RDF
John Graybeal
jbgraybeal at mindspring.com
Fri Nov 9 22:40:49 EST 2018
I am responding to Jonathan’s question about how to model the terms from other standards. I fully agree with Nan’s points.
I also believe option 2 is the best choice because it most closely reflects semantic community best practices. Semantic artifacts that reuse terms from other artifacts use the original identifier for that term.
That immediately comes back to Nan’s point, these do not have unique identifiers. This offers 3 approaches:
1) choose a clearly provisional IRI
2) choose a realistic and maybe correct IRI
3) get the principles at NUG etc to agree on appropriate IRI patterns
I think a best practice would be to try path 3 (you may hit pay dirt!), and fall back to path 1. You could even create any provisional terms you need as a hosted vocabulary in ORR or COR. Then they get remapped and deprecated later.
John
> On Nov 8, 2018, at 10:25, Nan Galbraith via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
>
> Hi all -
>
> I'm re-sending this because the list of recipients was too long on the
> original. Please excuse the duplication!
>
> I completely agree with Mark. We need to be clear that Conventions and
> title (etc) are not ACDD terms. That said ...
>
> There may be other code lists that we have adopted - specifically from
> ISO - where there is no real definition provided by the 'owner' of the
> term. These terms are presumably to be defined by communities. I don't
> think we have come up with a way to either provide our own definitions
> or to point to another group that has done so.
>
> The role codes (CI_RoleCode) is a good example. The definitions on
> https://standards.iso.org/iso/19115/resources/Codelist/cat/codelists.xml
> are sometimes circular:
> publisher: party who published the resource
> author: party who authored the resource
>
> These have usable definitions on the NOAA EDM (geo-ide) site at
> https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries
> publisher : the individual or organization who prepares and
> issues the resource.
> author: the individual or organization whose name should appear
> first in the citation for the resource
>
> So the term is owned by ISO, but we might want to consider some way to
> indicate that the definitions are available ... elsewhere, or that we've
> adopted a particular way to apply the terms. We have an ACDD 'ISO
> translation Notes' page, but I'm not sure it's very useful in its
> present form.
>
> There, we map 'creator' to the ISO term citation/citedResponsibleParty
> role=originator. Originator is defined by ISO as 'party who created the
> resource'. I find this to be too vague to be useful - is it the person
> who headed up the project, the person who wrote the NetCDF file, or ...
> someone else? The NOAA EDM definition - author - is far more clear, at
> least to me.
>
> Cheers - Nan
>
>
>> On 11/8/18 10:06 AM, Hedley, Mark wrote:
>> Hello
>>
>> I think that Option 1:
>> "
>> -Option 1: Include equivalence statements across communities-
>> acdd:title <=> cf:title <=> nug:title
>> acdd:Conventions <=> cf:Conventions <=> nug:Conventions
>> "
>>
>> presents particular concerns. I am not in favour of this approach.
>>
>> I think these semantics give the impression that that ACDD and CF
> deHi all -
>
> I'm re-sending this because the list of recipients was too long on the
> original. Please excuse the duplication!
>
> I completely agree with Mark. We need to be clear that Conventions and
> title (etc) are not ACDD terms. That said ...
>
> There may be other code lists that we have adopted - specifically from
> ISO - where there is no real definition provided by the 'owner' of the
> term. These terms are presumably to be defined by communities. I don't
> think we have come up with a way to either provide our own definitions
> or to point to another group that has done so.
>
> The role codes (CI_RoleCode) is a good example. The definitions on
> https://standards.iso.org/iso/19115/resources/Codelist/cat/codelists.xml
> are sometimes circular:
> publisher: party who published the resource
> author: party who authored the resource
>
> These have usable definitions on the NOAA EDM (geo-ide) site at
> https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries
> publisher : the individual or organization who prepares and
> issues the resource.
> author: the individual or organization whose name should appear
> first in the citation for the resource
>
> So the term is owned by ISO, but we might want to consider some way to
> indicate that the definitions are available ... elsewhere, or that we've
> adopted a particular way to apply the terms. We have an ACDD 'ISO
> translation Notes' page, but I'm not sure it's very useful in its
> present form.
>
> There, we map 'creator' to the ISO term citation/citedResponsibleParty
> role=originator. Originator is defined by ISO as 'party who created the
> resource'. I find this to be too vague to be useful - is it the person
> who headed up the project, the person who wrote the NetCDF file, or ...
> someone else? The NOAA EDM definition - author - is far more clear, at
> least to me.
>
> Cheers - Nan
>
>
>> On 11/8/18 10:06 AM, Hedley, Mark wrote:
>> Hello
>>
>> I think that Option 1:
>> "
>> -Option 1: Include equivalence statements across communities-
>> acdd:title <=> cf:title <=> nug:title
>> acdd:Conventions <=> cf:Conventions <=> nug:Conventions
>> "
>>
>> presents particular concerns. I am not in favour of this approach.
>>
>> I think these semantics give the impression that that ACDD and CF
> define a title attribute, when all they do is use the NUG title
> attribute in the same was as defined in the NUG
>> By declaring separate entities, we are potentially forcing parsing
> software that is trying to work out how to interpret title to choose
> between different definitions, potentially requiring that all of those
> definitions to be complete and include the same as (or similar) relations.
>> This has significant implications for software delivery.
>> I strongly advocate that any use of NUG attributes within CF and
>> ACDD recognise that these are NUG attributes and do not include their own
> definition of the same term
>
>> many thanks
>>
>> Mark Hedley
>>
>> ________________________________________
>> From: Armstrong, Edward M (398G) <Edward.M.Armstrong at jpl.nasa.gov>
>> Sent: 08 November 2018 02:01
>> Subject: Re: [Esip-documentation] Fwd: [esip-semantictech] ACDD vocab as RDF
>>
>> Hi Jonathan:
>>
>> I think that Option 1 is reasonable.
>>
>>
>> On 11/7/18, 3:57 PM, "Jonathan.Yu at csiro.au" <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
>
>> Regards,
>> Jonathan
>>
>> -----Original Message-----
>> From: Nan Galbraith [mailto:ngalbraith at whoi.edu]
>> Sent: Tuesday, 6 November 2018 7:00 AM
>> 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 on behalf of David Neufeld > *Date: *Monday, November 5, 2018 at 8:36 AM
>> > *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 > Date: Sun, Nov 4, 2018 at 7:38 PM
>> > Subject: [esip-semantictech] ACDD vocab as RDF
>> > To: <esip-semanticweb at lists.esipfed.org
>> >
>> > 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/
>> >
>> > 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>). This might
>> > hook into some of the discussion about 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
>> > very_1-3)
>> > into CSV.
>> >
>> > This is being developed over at https://github.com/ESIPFed/acdd (see
>> > PR 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/%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 for
>> > an initial schema.org <http://schema.org> mapping.
>> >
>>
>
>
> --
> *******************************************************
> * 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
> https://lists.esipfed.org/mailman/listinfo/esip-documentation
More information about the Esip-documentation
mailing list