nielsklazenga
commented
5 years ago Closed nielsklazenga closed 5 years ago
nielsklazenga
commented
5 years ago 
baskaufs
commented
5 years ago I just put a comment as a response to Niels' comment about the possibility of having both relationshipCategories as direct properties on the Name Usage and as separate instances of relationships. I've created a new slide 6 in the "name diagram" Google slide deck that shows graphically how this could work. I wrote a "dumb down" rule, similar to the one for turning SKOS-XL labels into vanilla SKOS labels as described in the SKOS reference. In this case, I just wrote out a text rule vs. one that could actually be implemented by inferencing. But one could easily write a SPARQL construct query that would do the "dumb down" job.
If you look at slide 7, you can see how the two systems would be used. In the case where there are separate relationship instances, the relationships would have to be in a separate table from the Name Usage metadata table. So by it's nature, this system is not as "flat". However, the dumbed-down version could be in a single flattened table. It would require having a column for every possible relationship type, which wouldn't be that bad if there weren't too many of them.
The advantage of having the separate relationship instance table is that you could then say more things about the relationships, such as who asserted them and when. Recording that information would not be possible in the flatter table. One could go from the more complex system to the simpler one by the dumb-down operation, but not in the other direction.
One additional comment is that the draft has "relationshipType" as a minted property. I am thinking that we would actually not need to mint a new property. It is conventional to link a thing to a SKOS property that categorizes it by a dcterms:subject property. That's exactly the situation we have here: the "relationshipType" triple actually explains the subject of the relationship (that is, the "subject" sensu Dublin Core, not sensu RDF). I think that having the object of the dcterms:subject triple being a SKOS concept is appropriate. It's essentially a controlled vocabulary term for relationship types, and SKOS concept schemes is the appropriate way to create a controlled vocabulary.
nielsklazenga
commented
5 years ago Meeting report for the first meeting is now on the Wiki.
nielsklazenga
commented
5 years ago Thanks @baskaufs. It didn't occur to me at the meeting when @camwebb asked me, but TCS has different types for TaxonRelationship and TaxonRelationshipAssertion:
The TDWG Taxon Concept LSID Ontology only has one, Relationship. This type has a fromTaxon, but no accordingTo, so I think it is more like the TaxonRelationship type in TCS.
My comment was about the hasRelationship term, adopted from the TDWG Ontology, which has this Relationship type as its range. So this comment was not about dumbing down, as no information is lost, or about flattening, as many of the relationship types are many-to-many, so, if you want to flatten it out, you need a relationship object (or file).
I think we should have only the RelationshipAssertion object, which is what we have, although we haven't called it that yet, and the hasRelationship property should have as its range an array of these assertions for which the subjectTaxonomicNameUsage is the TaxonomicNameUsage.
I think though that there is some semantic dumbing down in just dumping all types of relationships into relationship assertions, so, at the moment, rather than having the possibility of having all relationships as either relationships or properties of their own, I would like to see some relationships that are always many-to-one (or one-to-many) and that are important to us, like 'protonym', 'basionym' and (heterotypic) 'synonym' as properties (it would have to be 'acceptedNameUsage' for synonyms, as that is where the 'one' side of the relationship is) and all other relationships that either can be or necessarily are many-to-many as 'relationship'. In my mind, this would do justice to the fundamental difference between 'synonym' and, e.g. 'misapplied name'. But that is for the next meeting.
I don't know exactly what I was thinking when I wrote the comment, but, if it was the same as I am thinking now, my examples of 'congruentWith' and 'includedIn' were poorly chosen (so it probably wasn't).
BTW. This was just to explain where I think my comment may have come from, and doesn't mean I don't agree with what @baskaufs did in the slide (as I do agree).
The next set of meetings is on Tuesday, 7 May at 21:00 UTC and Wednesday, 8 May at 08:00 UTC.
Like last time, we'll make an attempt to start with the TNU relationships, but there are a few things that came out of the previous meetings that need to be revisited first. More information to follow...
First meeting times:
Second meeting times: