search

ESIPFed / sweet

Official repository for Semantic Web for Earth and Environmental Terminology (SWEET) Ontologies
Other
115 stars 33 forks source link

ISSUE-181 Annotating Geologic Feature and dissassociating from Realm #182

Closed nicholascar closed 4 years ago

nicholascar commented 4 years ago

I have added standard SKOS annotation properties to Geologic Feature and removed the statement making it a subclass of sorea:PlanetaryRealm.

These changes follow discussion at Issue #181

If this PR is merged, the intention of the Geological Survey of Queensland is to flesh out the subclasses of Geologic Feature - both the range and their details. We will also consider improving the positioning of Geologic Feature within the total SWEET ontology since the relationship to sorea:PlanetaryRealm will have been broken.

smrgeoinfo commented 4 years ago

note that this update makes GeologicFeature a direct subclass of owl:Thing. Should be OK for now.

nicholascar commented 4 years ago

note that this update makes GeologicFeature a direct subclass of owl:Thing. Should be OK for now.

Yes, I think, given the scale of the required review of the Realm subsumptions, we're just best off doing this for now, getting the definition here in, and then tackling the other parts elsewhere.

lewismc commented 4 years ago

Yes, I think, given the scale of the required review of the Realm subsumptions, we're just best off doing this for now, getting the definition here in, and then tackling the other parts elsewhere.

I agree... a moving target is OK. COR facilitates users that wish to request different/previous versions of IRI's should they need to.

nicholascar commented 4 years ago

@lewismc I did read the Recognition of SWEET Contributors and I remember talking about it in the last teleconference too.

What I've done here is follow the spirit of the guidance but not the particulars, precisely to see what you all make of it! This is perhaps a v1.1, simplified version, of the 'largely agreed' work and, if the reasoning below stacks up, I'd like to refine the attribution proposal in line with this.

My main reasoning for what I've done is:

I've documented the schema.org (and other) Agent attributions for ontologies within pyLODE, e.g.:

<ontology_x> # or SWEET class of course
    dct:creator [
        schema:name "Nicholas J. Car" ;
        schema:identifier <http://orcid.org/0000-0002-8742-7730> ;
        schema:email <mailto:nicholas.car@surroundaustralia.com> ;
    ] ;

I've not bothered with temporality of Person/Org affiliation in pyLODE yet but I could include it if I'm convinced it's really needed (since you know, at the time such a declaration was made the association is/was true)! It just looks like too much info for now...

In the end, I'm happy to revert to the 'largely agreed' work if this reasoning either doesn't stack up or is just not appropriate... But I will need a way to do that direct Org association...

lewismc commented 4 years ago

@nicholascar this all sounds totally reasonable and you make solid compelling points. I propose that we go back and update the guidance for this as well. We need to be clear about how one would distinguish between

graybeal commented 4 years ago

I don't see a role mentioned in the dialog about the Contribution pattern, and it isn't clear to me how an organization by itself helps in identifying the individual involved or in what capacity they are making the change. (Yes, you know you are making it on behalf of others, but how will that be obvious to later viewers?)

While I don't necessarily mind the notion of change, I think discussing and approving(?) a change to the Contributors process within an issue on another topic isn't really an appropriate practice, and this change should be explicitly raised and discussed in its own thread.

lewismc commented 4 years ago

@graybeal

I don't see a role mentioned in the dialog about the Contribution pattern

Can you clarify role please?

and it isn't clear to me how an organization by itself helps in identifying the individual involved or in what capacity they are making the change.

My response to this is that Nic is probably doing this whilst on the clock and employed by Geological Survey of Queensland. Therefore, arguably the IP contribution is essentially theirs not his. I would respect that. We clarify this over at the Apache Software Foundation through using Individual Contributor License Agreements (ICLAs) and Commercial Contributor License Agreements (CCLAs).

(Yes, you know you are making it on behalf of others, but how will that be obvious to later viewers?)

I agree with this. I don't have any response which resolves the point you raise.

While I don't necessarily mind the notion of change, I think discussing and approving(?) a change to the Contributors process within an issue on another topic isn't really an appropriate practice, and this change should be explicitly raised and discussed in its own thread.

We've been discussing the topic of change management since the AGU Workshop in December. We made serious progress in December. We proposed it again at ESIP earlier this month and there was some healthy disagreement. Quite clearly we are still not there yet!

I propose that we consider the 2 following contribution options and the impact that each of these would have on the end result

graybeal commented 4 years ago

I don't see a role mentioned in the dialog about the Contribution pattern

Can you clarify role please?

Sorry, the relationship of the person making the changes to the organization or ontology (or of the organization to any parent entity). Even if the IP is the organization's, the person doing the creation might be the organizational representative in this matter, or acting on their own; the same person might occupy different roles for different changes.

The idea of Agent helps with this; the Agent generally has an associated role, if I am not mistaken.

We've been discussing the topic of change management since the AGU Workshop in December. We made serious progress in December. We proposed it again at ESIP earlier this month and there was some healthy disagreement. Quite clearly we are still not there yet!

To the extent its feasible, should these be summarized or referenced by a ticket, so those of us who are Github-driven can see the state of play?

I propose that we consider the 2 following contribution options and the impact that each of these would have on the end result

  • dcterms:creator of a new Class
  • dcterms:contributor to an existing Class

Separate ticket?

lewismc commented 4 years ago

Separate ticket?

Yes, I'll take that one on :)

lewismc commented 4 years ago

I updated https://github.com/ESIPFed/sweet/wiki/SWEET-Annotation-Convention... comments?

nicholascar commented 4 years ago

Regarding:

it isn't clear to me how an organization by itself helps in identifying the individual involved or in what capacity they are making the change.

(Yes, you know you are making it on behalf of others, but how will that be obvious to later viewers?)

I agree with this. I don't have any response which resolves the point you raise.

It's pretty common for Australian government agencies to require organisation-level attribution and not to the mention individuals who are the individual contributors. So you'd read attribution to an organisation as just that. If I wanted, or was allowed, to be attributed personally, I would have done this:

    dcterms:contributor [
        a sdo:Person ;
        sdo:name "Nicholas J. Car" ;
        sdo:identifier <https://orcid.org/0000-0002-8742-7730> .
        sdo:affiliation [
            a sdo:Organization ; 
            sdo:name "Geological Survey of Queensland" ;
            sdo:identifier <http://linked.data.gov.au/org/gsq> .
        ]
    ] ;

...without any attribution temporality since, as I've mentioned before, I think that's overkill: the affiliation is important so you know what Org the Person was affiliated with at the time of the contribution, not so you can piece together the person's job history from every contribution they've made!

dr-shorthair commented 4 years ago

I agree with Nick on the requirement. However, in this case it might make more sense for the direction of the affiliation to be reversed - e.g. 

 dcterms:contributor [
        a sdo:Organization ; 
        sdo:name "Geological Survey of Queensland" ;
        sdo:identifier <http://linked.data.gov.au/org/gsq> .
        sdo:employee [
            a sdo:Person ;
            sdo:name "Nicholas J. Car" ;
            sdo:identifier <https://orcid.org/0000-0002-8742-7730> .
        ]
    ] ;

(this is not quite right, but all I could roll from schema.org quickly)

nicholascar commented 4 years ago

@dr-shorthair

...in this case...

In this particular case, I'm not seeking individual attribution so I'll go with the original 

 dcterms:contributor [
        a sdo:Organization ; 
        sdo:name "Geological Survey of Queensland" ;
        sdo:identifier <http://linked.data.gov.au/org/gsq> .
    ] ;

But, in the general case I disagree with the proposal to use sdo:employee or similar as it's not clear how the stated employee relates to the Organization as contributor: since we have the Open World assumption, with this construct we see that the Organization is a contributor and that it has an employee but we can't infer that the particular employee given was the contributing employee.

I think it much clearer where there's a Person agent contributing/creating, to then state their affiliation as that's unambiguous. So I think we should allow Org or Person agents and allow affiliations but not employee or similar hasMember.

smrgeoinfo commented 4 years ago

What is gained by using the sdo elements on dcterms:contributor, instead of the equivalent dcterms vocab? When the example from the wiki (https://github.com/ESIPFed/sweet/wiki/SWEET-Annotation-Convention#update-an-existing-class-using-your-organization-as-your-identifier) is put in the google structured data testing tool, it doesn't recognize any of the sdo content.

dr-shorthair commented 4 years ago

@nicholascar Of course employee is not the correct predicate. I just grabbed one that had domain Organization, range Person. It was merely that graph shape that I was trying to illustrate.

nicholascar commented 4 years ago

What is gained by using the sdo elements on dcterms:contributor, instead of the equivalent dcterms vocab?

Are you suggesting that all of the SDO terms I've used can be replaced with DCT terms? If so, for something like this (not that I'm proposing the person + affiliation for this specific update):

dcterms:contributor [
    a sdo:Person ;
    sdo:name "Nicholas J. Car" ;
    sdo:identifier <https://orcid.org/0000-0002-8742-7730> .
    sdo:affiliation [
        a sdo:Organization ; 
        sdo:name "Geological Survey of Queensland" ;
        sdo:identifier <http://linked.data.gov.au/org/gsq> .
    ]
] ;

What do you propose we use for:

DCT only has an Agent class (no Organization or Person), we can use dct:identifier instead of sdo:identifier perhaps, but DCT also has no sdo:name equivalent (name of an Agent, not a creative work title) and absolutely no sense of Agent/Agent relations like sdo:affiliation.

...the google structured data testing tool, it doesn't recognize any of the sdo content.

Let's step towards fixing that! I do want this edit with the definition to actually go through and then we can debate further updates to knock off such nice-to-haves.

Can you approve now?

nicholascar commented 4 years ago

@lewismc well that's 3x ok reviews, can this be merged please?

I have a pile of subclasses of it, with great literature-based definitions, ready to go on Wednesday!

lewismc commented 4 years ago

Sorry @nicholascar for the delay.

@smrgeoinfo @dr-shorthair @nicholascar any of you should be able to merge this in the future as well.