Replies: 56 comments 5 replies
-
|
It opens up the standard for alternative representations. This shifts the problem to consumers that now have to check different places for the same information. I personally think this is a bigger problem than for the producer, so I would try to avoid this as much as possible. It is also an issue you find in DwC, ABCD and TCS1 where there are parsed and unparsed strings for the same thing. The more options a standard has, the less of a standard it is :) |
Beta Was this translation helpful? Give feedback.
-
|
@mdoering Good point. I concede that for standardization of data transfer, having a single way to 'officially' do something is best. |
Beta Was this translation helpful? Give feedback.
-
|
I transferred this issue from the TNC repo. a few weeks ago, because I think we should consider making the relationship types TCS properties, rather than controlled terms in an external vocabulary. I actually think we should do it, but I have been flip-flopping around on this issue a bit (privately; publicly I think this is the first time I am saying something about it). At the moment I even think we can do without the Taxon Relationship class altogether, but we might need it again when we want to add additional properties like whether the statement reflects the ostensive or intensional component of the relationship. On the other hand, that might be the time to add the class, rather than now. Having the relationship types as TCS properties enables us to do things like this: <https://id.biodiversity.org.au/instance/apni/545068> a tcs:TaxonConcept ;
dcterms:title "Euphrasia gibbsiae sec. Barker 1982" ;
tcs:accordingTo <https://www.jstor.org/stable/23873848> ;
tcs:acceptedName <https://www.ipni.org/n/802545-1> ;
tcs:synonym <https://www.ipni.org/n/802619-1> ;
tcs:intersects <https://id.biodiversity.org.au/instance/apni/713514> .
<https://id.biodiversity.org.au/instance/apni/713514> a tcs:TaxonConcept ;
dcterms:title "Euphrasia gibbsiae sec. Curtis 1967" ;
tcs:accordingTo <https://id.biodiversity.org.au/reference/apni/23028> ;
tcs:acceptedName <https://www.ipni.org/n/802545-1> .... and, for a third-party taxon relationship assertion, in the body of an annotation or a nano-publication: _:someone_elses_assertion a rdf:Statement ;
rdf:subject <https://id.biodiversity.org.au/instance/apni/545068> ;
rdf:predicate tcs:includes ;
rdf:object <https://id.biodiversity.org.au/instance/apni/713514> .I think I might be committing RDF sacrilege with the latter example, but this is just how I think it could work and someone else can correct me. I think doing this makes TCS 2 more simple and flexible and more like a proper TDWG vocabulary standard, i.e. a set of terms and definitions. I acknowledge that it is rather late in the game to make significant changes, so if we cannot quickly agree on this we will table it, but if we can we might as well get it right from the start, so let's at least talk about it. At least at the moment I think this is right. Defining taxon relationship assertions as "Things" has always bothered me for some reason – and we have had some issues with naming the class (#43) – and now I think that might be because they are mere data structures and should not have a domain-specific class. Relationships between objects are generally recorded using properties. I also think it is not that much of a change and possibly a big improvement. |
Beta Was this translation helpful? Give feedback.
-
|
I've always disliked the existing implementation of TC Relationships with the 'From' and the 'To' TCs, and agree in simple cases making the relationship types into different properties would be cleaner and simple. But... in our case, almost always we want to encode the 'according to' of the relationship - who asserted it. Which would mean reifying the statement every single time. I think the essence of the issue this: will there almost always be metadata about the TC relationship that needs to be encoded in the data transmission model? If so, we should probably stick with what we have. The problem is a generic one with modelling in RDF. Graph DBs (and their ASCII encodings) allow edges to have properties, which permits a more 'natural' graph. In RDF you always need an intermediate node to hang edge metadata on. I'm sure there has been extensive discussion of the pros and cons of writing a schema such that reification must always be used (for full data transmission). In practice, I haven't seen reification used as a core technology. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @camwebb, have a look at the examples I put in https://github.com/tdwg/tcs2/tree/examples-stash/docs/examples/taxon-relationships-redone. As this branch will disappear at some point, I will repeat some here for the sake of longevity. So, a Taxon Concept with horizontal relationships between taxa looks like this: @prefix tcs: <http://rs.tdwg.org/tcs/terms/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
[] a tcs:TaxonConcept ;
dcterms:title "Campylium sec. Koperski et al. 2000" ;
tcs:accordingTo <https://tropicos.org/reference/9022656> ;
tcs:acceptedName <https://tropicos.org/name/35000208> ;
tcs:synonym <https://tropicos.org/name/35101378> ,
<https://tropicos.org/name/35101264> ;
tcs:isConguentWith [ a tcs:TaxonConcept ;
dcterms:title "Campylium sec. Corley et al. 1981" ;
tcs:accordingTo <https://tropicos.org/reference/9004554> ;
tcs:acceptedName <https://tropicos.org/name/35000208> ] ;
tcs:includes [ a tcs:TaxonConcept ;
dcterms:title "Campylium sec. Smith 1980" ;
tcs:accordingTo <https://tropicos.org/reference/9007023> ;
tcs:acceptedName <https://tropicos.org/name/35000208> ] ;
tcs:partiallyOverlaps [ a tcs:TaxonConcept ;
dcterms:title "Chrysohypnum sec. Moenkemeyer 1927" ;
tcs:accordingTo <https://tropicos.org/reference/9021085> ;
tcs:acceptedName <https://tropicos.org/name/35000256> ] ,
[ a tcs:TaxonConcept ;
dcterms:title "Drepanocladus sec. Moenkemeyer 1927" ;
tcs:accordingTo <https://tropicos.org/reference/9021085> ;
tcs:acceptedName <https://tropicos.org/name/35000413> ] ;
tcs:intersects: [ a tcs:TaxonConcept ;
dcterms:title "Campylium sec. Frahm & Frey 1992" ;
tcs:accordingTo <https://tropicos.org/reference/9011497> ;
tcs:acceptedName <https://tropicos.org/name/35000208> ] ;
rdfs:comment """Weltweit über 30 Arten, in Europa 9 Arten (incl. *C.
laxifolium Engelmark & Hedenäs 1990) – Hedenäs (1997a) akzeptiert
auch die Gattungen Campyliadelphus und Campylophyllum und stellt
Campylium polygamum zur Gattung Drepanocladus.""" .One of these relationships, with a comment, looks like this: @prefix tcs: <http://rs.tdwg.org/tcs/terms/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
[] a rdf:Statement ;
rdf:subject _:tc-2000-Campylium ;
rdf:predicate tcs:includes ;
rdf:object _:tc-1980-Campylium ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment """excl. *C. longicuspis (Lindb. & Arnell) Hedenäs (syn.
*Amblystegium l. Lindb. & Arnell, *Drepanocladus l. (Lindb. &
Arnell) Broth., Pseudocalliergon l. (Lindb. & Arnell) Loeske), da
Hedenäs diese Kombination erst 1989 schuf. Es bleibt unklar zu
welcher Gattung SMITH dieses auf den Britischen Inseln nicht
nachgewiesene Taxon stellt""" .I came across the RDF Reification Vocabulary serendipitously when I happened to read the RDF Schema specification, but it turns out @baskaufs had already suggested using it two years ago, in a presentation at TDWG 2021, to deal with Regarding your statement that you 'haven't seen reification used as a core technology', I think that is not true, as you are using reification whether you use the Vocabulary or not, so we were already using reification for the relationships between taxa. Especially when serialising as tabular data – and storing data in a relational database – reification is used all the time to resolve many-to-many relationships. Also, serialisation should not be a concern of a Vocabulary Standard, which is one of the reasons why we are having so much trouble with the I am not opposed to still having a |
Beta Was this translation helpful? Give feedback.
-
|
TCS 1 has With that, the proposal is simply as follows:
The first dot point is the original GitHub issue (#225), although I think that proposed to have both the SKOS vocabulary and the TCS properties. This brings TCS 2 closer to TCS 1, as in TCS 1 the taxon relationships could also be embedded in the Taxon Concept. Additionally, rather than defining a TCS property So, the example before becomes: @prefix tcs: <http://rs.tdwg.org/tcs/terms/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
_:tc-2000-Campylium a tcs:TaxonConcept ;
dcterms:title "Campylium sec. Koperski et al. 2000" ;
tcs:accordingTo <https://tropicos.org/reference/9022656> ;
tcs:acceptedName <https://tropicos.org/name/35000208> ;
tcs:synonym <https://tropicos.org/name/35101378> ,
<https://tropicos.org/name/35101264> ;
rdfs:comment """Weltweit über 30 Arten, in Europa 9 Arten (incl. *C.
laxifolium Engelmark & Hedenäs 1990) – Hedenäs (1997a) akzeptiert
auch die Gattungen Campyliadelphus und Campylophyllum und stellt
Campylium polygamum zur Gattung Drepanocladus.""" .
[] a tcs:TaxonRelationshipAssertion ;
rdf:subject _:tc-2000-Campylium ;
rdf:predicate tcs:includes ;
rdf:object [ a tcs:TaxonConcept ;
dcterms:title "Campylium sec. Corley et al. 1981" ;
tcs:accordingTo <https://tropicos.org/reference/9004554> ;
tcs:acceptedName <https://tropicos.org/name/35000208> ] ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment """excl. *C. longicuspis (Lindb. & Arnell) Hedenäs (syn.
*Amblystegium l. Lindb. & Arnell, *Drepanocladus l. (Lindb. &
Arnell) Broth., Pseudocalliergon l. (Lindb. & Arnell) Loeske), da
Hedenäs diese Kombination erst 1989 schuf. Es bleibt unklar zu
welcher Gattung SMITH dieses auf den Britischen Inseln nicht
nachgewiesene Taxon stellt""" ....and assertions without a source look like: @prefix tcs: <http://rs.tdwg.org/tcs/terms/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
[] a tcs:TaxonRelationshipAssertion ;
rdf:subject <https://avibase.ca/82745BAA> ;
rdf:predicate tcs:includes ;
rdf:object <https://avibase.ca/F558C7F9> ;
dcterms:creator <https://orcid.org/0000-0003-2224-6821> ;
dcterms:created "2023-07-31" .
[] a tcs:TaxonRelationshipAssertion ;
rdf:subject <https://avibase.ca/82745BAA> ;
rdf:predicate tcs:includes ;
rdf:object <https://avibase.ca/A091D50A> ;
dcterms:creator <https://orcid.org/0000-0003-2224-6821> ;
dcterms:created "2023-07-31" .
[] a tcs:TaxonRelationshipAssertion ;
rdf:subject <https://avibase.ca/F558C7F9> ;
rdf:predicate tcs:isDisjointWith ;
rdf:object <https://avibase.ca/A091D50A> ;
dcterms:creator <https://orcid.org/0000-0003-2224-6821> ;
dcterms:created "2023-07-31" . |
Beta Was this translation helpful? Give feedback.
-
|
Just to follow up on what @nielsklazenga said, Darwin Core basically uses the reification model in the dwc:ResourceRelationship class. When we wrote the DwC RDF Guide, we deferred on how to represent those terms in RDF and as I suggested in that talk Niels mentioned, using the RDF subject, predicate, and object reification properties would be a way to express resource relationships without minting new DwC If Darwin Core were to adopt what I proposed, then following the approach that Niels suggests in TCS2 would result in consistent modeling across TDWG, which makes more sense to me than to develop yet another system that does the same thing as the ReasourceRelationship terms and the RDF reification vocabulary. I get what @camwebb said about reification not often being used as a core technology. But for better or worse, TCS2 is basically being defined using RDF, so using terms from the core RDF vocabulary to define the relationships makes sense to me and should be understandable by people outside of our community. That would not stop anyone in their own graph database from collapsing down the relationships as direct edges with properties, since Niels is proposing minting properties for the relationships ( |
Beta Was this translation helpful? Give feedback.
-
|
@nielsklazenga , let's try and avoid reification wherever possible (blank nodes too). My preference is to continue with an extensible, generic Relationship class, sub-typed as necessary, that can be bundled or used stand-alone without reification. A bodgied (ChatGPT) example for illustration, no attempt to be TCS or RDF compliant. |
Beta Was this translation helpful? Give feedback.
-
|
Note that my proposal (or @camwebb's proposal as adulterated by me) does not introduce reification to TCS or adds more reification to TCS. Whenever there is a relationship object, there is reification, no matter what namespace the properties are in. In fact this proposal reduces the amount of reification (and my original proposal removed it altogether) by not hard-coding it into TCS, but leaving it to the data and/or the implementation whether reification is needed. The proposal also does not add any new terms to TCS. In fact, it reduces the number of terms defined in TCS by borrowing syntax terms from other specifications that are specifically designed for that. A "generic Relationship class" is already in Darwin Core in the form of the So, the only question (regarding relationship classes) in the purview of the TCS 2 Task Group is whether or not we keep the TaxonRelationshipAssertion class (ignoring the issue of the name of the class for now). As TaxonRelationshipAssertion is a top-level element in TCS 1 and since we have translated those top-level elements to classes in TCS 2, there needs to be unanimous consent to remove it, so I think we have no choice but to keep it, although I personally think this sort of stuff does not belong in a Standard but in an Application Profile. We can discuss whether we define the properties of the TaxonRelationshipAssertion class in TCS (like we're doing now) or borrow them from RDF and Dublin Core, but this is also not entirely up to us, as the final decision is not ours and I think people generally will prefer a TDWG wide solution rather than have different standards do different things. I think we should do whatever gives us the highest chance of ratification, so all our work has not been for nothing. |
Beta Was this translation helpful? Give feedback.
-
|
There is a big difference between using reification as a principle in concept modelling and the very specific use case in RDF for making statements about statements to capture edge metadata. A model that supports reified content does not need reification in RDF. This might sound trivial, but it has implications for what can be delivered using the model and the ease with which data can be queried and processed. Not least is @camwebb 's comment about best practices and then the model’s standing. The advantage of the TaxonRelationshipAssertion model is that it can be extended with controlled vocabulary amendments rather than ontology change. I don’t imagine there will be support for 25 additional data properties for the “taxon” relationships we publish already. |
Beta Was this translation helpful? Give feedback.
-
|
I do not think it gets any more general than RDF and your example looks just as RDF-y as mine but okay, so if we have the TaxonRelationshipAssertion class you do not want to use the RDF properties on it. My argument is that the TCS TaxonRelationshipAssertion is the same thing as the Darwin Core ResourceRelationship class, so I think it should be dealt with the same way. I think that makes it not our concern but that of the Darwin Core Maintenance Group or the TAG and I think especially the latter group is much better placed to discuss this. Also, the authors of the Darwin Core RDF Guide, the Darwin Core and RDF/OWL Task Groups, when they could not immediately find a good way to deal with the ResourceRelationship class in RDF (they actually say that 'it is not clear whether Anyway, the reification people are worried about is only in the first example, and I made very clear that it was just an example to show that we do not need a "Relationship" class (I also said that 'I think I might be committing RDF sacrilege...'). So, I am not sure how a dislike for RDF reification can be used to oppose my proposal. It actually sort of makes my point (or misses the point), especially as now the argument seems to be that reification is okay as long as you do not do it in RDF, so you can just use the
The inline examples in the Term List, my TCS has neither a model nor an ontology. The TCS Term List is a vocabulary just like a controlled vocabulary and the process for adding a property to the Term List or a controlled term to a controlled vocabulary is exactly the same. Topological relationships are properties in things like GeoSPARQL and SKOS, so it makes sense to do the same in TCS. Idiosyncrasy is not exactly a desirable feature in a standard. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, @camwebb has gone bush and we will not hear from him before August 21st. |
Beta Was this translation helpful? Give feedback.
-
|
I will just verify what @nielsklazenga said about properties and controlled values. If they are part of a standard, they (as well as classes) are all vocabulary terms and subject to exactly the same change process. @ghwhitbread I do not understand your point. You are OK with reification as a principle in concept modelling, but not with using the RDF reification terms to describe it. What is the issue? The reification terms are very lightweight and carry no significant semantics (except that they describe relationships). I don't see the point of minting our own terms that mean the same thing as ones that are already well known, which seems to be what you are doing in the One of the roles of the TAG is to promote interoperability and to prevent TDWG standards from duplicating each other's work. What TCS is trying to do in describing taxon relationships is entirely analogous to what Darwin Core already does with ResourceRelationship terms. As Niels said, the DwC RDF Guide avoided creating As TAG convener, what I would like to see us settle on is a TDWG-wide consensus on how we can describe these kind of relationships in RDF, particularly as we move toward JSON-LD as a machine-readable way to expose data whose semantics are clear. It seems to me that the RDF reification terms serve as a simple and well-known way to do that, so that's why I'd like to understand better what your objection to them is. |
Beta Was this translation helpful? Give feedback.
-
|
Getting back to something that @ghwhitbread said earlier:
I think the bit in parentheses is actually the most important. The most important reason to have a class for these relationships in TCS is that we need IDs on these things. In the discussion in issue #43 the name we ended up with—before I started to muck around with it in the examples—was 'TaxonConceptAlignment'. I think a TaxonConceptAlignment (or ...Mapping) class would be very useful to have. In fact, it is kind of essential, as the definition of TaxonConcept relies on it. I still do not want to mint any of its properties in TCS, as it is still a Resource Relationship, even though it is a specific type of Resource Relationship that is very important to us. The reason, by the way, why I went back to TaxonRelationship is that I wanted to use the relationships more widely than only for concept mappings. Especially the Further on the blank nodes, I think we need to reconsider how we deal with this in the examples. In an earlier meeting, we decided that we should not make up IRIs if they do not already exist. However, after looking at online taxonomic systems to find examples (for the Term List and the Implementation Experience Report), I now think that the next challenge to overcome is the lack of citable identifiers for all our objects and that it is often not clear what object an identifier applies to. I think (now) it is important to set a good example and have IRIs on all the objects we define in TCS at least. We will talk more about this in our next meeting (I am planning one for the end of August). |
Beta Was this translation helpful? Give feedback.
-
|
#I:heart:reification: @prefix tcs: <http://rs.tdwg.org/tcs/terms/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<https://eg.tdwg.org/tcs/tc/2000-Amblystegium> a tcs:TaxonConcept ;
dcterms:title "Amblystegium sec. Koperski et al. 2000" ;
tcs:accordingTo <https://tropicos.org/reference/9022656> ;
tcs:acceptedName <https://tropicos.org/name/35000040> ;
tcs:synonym <https://tropicos.org/name/35000612> ;
tcs:includes <https://eg.tdwg.org/tcs/tc/1981-Amblystegium> ,
<https://eg.tdwg.org/tcs/tc/1992-Amblystegium> ,
<https://eg.tdwg.org/tcs/tc/1992-Hygroamblystegium> ,
<https://eg.tdwg.org/tcs/tc/1927-Hygroamblystegium> ;
tcs:partiallyOverlaps <https://eg.tdwg.org/tcs/tc/1992-Amblystegiella> ,
<https://eg.tdwg.org/tcs/tc/1992-Campylium> ,
<https://eg.tdwg.org/tcs/tc/1927-Amblystegium> ,
<https://eg.tdwg.org/tcs/tc/1927-Chrysohypnum> ,
<https://eg.tdwg.org/tcs/tc/1980-Amblystegium> ,
<https://eg.tdwg.org/tcs/tc/1980-Platydictya> ;
rdfs:comment """Weltweit etwa 35 Arten, in Europa 8 Arten. Abweichend von
Corley & al. Wird in Übereinstimmung mit Anderson & al. (1990),
Ignatov & Afonina (1992), Blockeel & Long (1998) sowie Crosby & al.
(1999) Leptodictyum als Gattung akzeptiert (s. auch Hedenäs
1990a)""" .
<https://eg.tdwg.org/tcs/tca/6> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:includes ;
rdf:object <https://eg.tdwg.org/tcs/tc/1981-Amblystegium> ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment "incl. Leptodictyum riparium (Amblystegium r.)" .
<https://eg.tdwg.org/tcs/tca/7> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:includes ;
rdf:object <https://eg.tdwg.org/tcs/tc/1992-Amblystegium> ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment """excl. Amblystegium confervoides (Amblystegiella c.), A.
subtile (Amblystegiella s.), A. fluviatile (Hygroamblystegium f.),
A. tenax (Hygroambystegium t.), A. radicale (Campylium r.)""" .
<https://eg.tdwg.org/tcs/tca/8> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:includes ;
rdf:object <https://eg.tdwg.org/tcs/tc/1992-Hygroamblystegium> ;
dcterms:source <https://tropicos.org/reference/9022656> .
<https://eg.tdwg.org/tcs/tca/9> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:includes ;
rdf:object <https://eg.tdwg.org/tcs/tc/1927-Hygroamblystegium> ;
dcterms:source <https://tropicos.org/reference/9022656> .
<https://eg.tdwg.org/tcs/tca/10> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:partiallyOverlaps ;
rdf:object <https://eg.tdwg.org/tcs/tc/1992-Amblystegiella> ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment """incl. Amblystegium confervoides (Amblystegiella c.),
Amblystegium subtile (Amblystegiella s.)""" .
<https://eg.tdwg.org/tcs/tca/11> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:partiallyOverlaps ;
rdf:object <https://eg.tdwg.org/tcs/tc/1992-Campylium> ;
dcterms:source <https://tropicos.org/reference/9022656> .
<https://eg.tdwg.org/tcs/tca/12> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:partiallyOverlaps ;
rdf:object <https://eg.tdwg.org/tcs/tc/1927-Amblystegium> ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment """incl. Conardia compacta (Amblystegium c.), *Isopterygiopsis
alpicola (Lind. & Arnell) Hedenäs (Amblystegium a.), Leptodictyum
riparium (Amblystegium r.), Platydictya jungermannioides
(Amblystegium sprucei), Pseudoleskeella catenulata p.p.
(Amblystegium ursorum) sowie die aussereuropäische Art *Homomallium
adnatum (Hedw.) Broth. (Amblystegium a.); excl. Amblystegium
fluviatile (Hygroamblystegium f.), A. tenax (Hygroamblystegium t.),
A. radicale (Chrysohypnum hygrophilum).""" .
<https://eg.tdwg.org/tcs/tca/13> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:partiallyOverlaps ;
rdf:object <https://eg.tdwg.org/tcs/tc/1927-Chrysohypnum> ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment "incl. Amblystegium radicale (Chrysohypnum hygrophilum)" .
<https://eg.tdwg.org/tcs/tca/14> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:partiallyOverlaps ;
rdf:object <https://eg.tdwg.org/tcs/tc/1980-Amblystegium> ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment """incl. Conardia compacta (Amblystegium c.), Leptodictyum
riparium (Amblystegium r.); excl. Amblystegium confervioides
(Platydictya c.)""" .
<https://eg.tdwg.org/tcs/tca/15> a tcs:TaxonConceptAlignment ;
rdf:subject <https://eg.tdwg.org/tcs/tc/2000-Amblystegium> ;
rdf:predicate tcs:partiallyOverlaps ;
rdf:object <https://eg.tdwg.org/tcs/tc/1980-Platydictya> ;
dcterms:source <https://tropicos.org/reference/9022656> ;
rdfs:comment "incl. Amblystegium confervoides (Platydictya c.)" . |
Beta Was this translation helpful? Give feedback.
-
I have now informally referred to them as 'concept mapping relationships' (in analogy to the |
Beta Was this translation helpful? Give feedback.
-
Yes, it's on my todo list. I've got several other things going on with the TAG right now but I hope to bring it up and this discussion will be very helpful background. |
Beta Was this translation helpful? Give feedback.
-
Since Niels has given his blessing to continuing to talk about RDF, I'll respond. Yes, you are right. I forgot about those entailment assertions in the SKOS model. I guess what I was thinking that a generic OWL reasoner would not materialize the simple triples based on the OWL properties of the terms -- you'd need to have a SKOS-aware system in order for those entailments to take effect (effectively making the choice to apply the entailments). But yes, following the model, they are entailed. This is making my brain hurt... :-) |
Beta Was this translation helpful? Give feedback.
-
Thanks @baskaufs . I will put something about it in the Implementation Experience Report as well (so you can at least wait for that). |
Beta Was this translation helpful? Give feedback.
-
Yeah, sorry, I'm not sure I have been making my thoughts very clear but thank you for taking the time to look at them and reply @baskaufs There is still a part of removing the tcs:TaxonRelationshipAssertion class and replacing its type vocabulary with object properties on the tcs:TaxonConcept that makes inference about the source of assertions tricky. But I concede that the entailment part is specific to RDF implementations and so outside the scope of TCS. Similarly if property assertions using TCS are (mostly) attributable to the file/datasource, like they are with Darwin Core, then figuring out where property assertions come from is trivial. Presumable as a TDWG standard, TCS is intended for use like this. So implementations that require more complex attribution of sources are likewise outside the scope of TCS. |
Beta Was this translation helpful? Give feedback.
-
|
@EndCoop, what has happened here in no way stops us from having a Taxon Relationship or Mapping object some day but, because of the unclarity around the use of the Also, regarding attribution, |
Beta Was this translation helpful? Give feedback.
-
|
Thanks all for the virtual meeting/discussion last week. @nielsklazenga, I like what you've done in the dev terms list. But a question on process: we left this matter (taxonRelationship with controlled vocab, as in TCS1, vs. new predicates) undecided at the meeting. Do you want a vote, or is the now a general sense that the predicate terms are better? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @camwebb, no, let's circle back to this later. By the way, @baskaufs (or yourself) might have to correct me, but I do not think there is anything that has happened here that prevents people from using these terms as controlled terms. @prefix tcs: <http://rs.tdwg.org/tcs/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
tcs:isCongruentWith a rdf:Property, skos:Concept ;
skos:prefLabel "is congruent with" ;
skos:altLabel "equals" ;
rdfs:comment """The subject and object taxon concepts have a congruent
taxonomic meaning, i.e. there is no conflict between the concepts""" ;
skos:definition """The subject and object taxon concepts have a congruent
taxonomic meaning, i.e. there is no conflict between the concepts""" ;
rdfs:isDefinedBy <http://rs.tdwg.org/tcs/terms> ;
skos:inScheme <http://rs.tdwg.org/tcs/terms> .
tcs:includes a rdf:Property, skos:Concept ;
skos:prefLabel "includes" ;
skos:altLabel "has proper subset" ;
rdfs:comment """The subject taxon concept has a more inclusive
taxonomic meaning than the object taxon concept""" ;
skos:definition """The subject taxon concept has a more inclusive
taxonomic meaning than the object taxon concept""" ;
rdfs:isDefinedBy <http://rs.tdwg.org/tcs/terms> ;
skos:inScheme <http://rs.tdwg.org/tcs/terms> .
tcs:isIncludedIn a rdf:Property, skos:Concept ;
skos:prefLabel "is included in" ;
skos:altLabel "is proper subset of" ;
rdfs:comment """The subject taxon concept has a less inclusive
taxonomic meaning than the object taxon concept""" ;
skos:definition """The subject taxon concept has a less inclusive
taxonomic meaning than the object taxon concept""" ;
rdfs:isDefinedBy <http://rs.tdwg.org/tcs/terms> ;
skos:inScheme <http://rs.tdwg.org/tcs/terms> .
tcs:partiallyOverlaps a rdf:Property, skos:Concept ;
skos:prefLabel "partially overlaps" ;
skos:altLabel "overlaps" ;
rdfs:comment """The subject and object taxon concepts have partially
overlapping taxonomic meanings, i.e. they have some members
in common, but each concept in addition has members that are
not included in the other concept""" ;
skos:definition """The subject and object taxon concepts have partially
overlapping taxonomic meanings, i.e. they have some members
in common, but each concept in addition has members that are
not included in the other concept""" ;
rdfs:isDefinedBy <http://rs.tdwg.org/tcs/terms> ;
skos:inScheme <http://rs.tdwg.org/tcs/terms> .
tcs:isDisjointFrom a rdf:Property, skos:Concept ;
skos:prefLabel "is disjoint from" ;
skos:altLabel "excludes" ;
rdfs:comment """The subject and objects taxon concepts have non-overlapping
taxonomic meanings, i.e. they do not have any members in common""" ;
skos:definition """The subject and objects taxon concepts have non-overlapping
taxonomic meanings, i.e. they do not have any members in common""" ;
rdfs:isDefinedBy <http://rs.tdwg.org/tcs/terms> ;
skos:inScheme <http://rs.tdwg.org/tcs/terms> .
tcs:intersects a rdf:Property, skos:Concept ;
skos:prefLabel "intersects" ;
rdfs:comment """The taxonomic meanings of the subject and object taxon
concepts intersect, i.e. they have at least one member in common""" ;
skos:definition """The taxonomic meanings of the subject and object taxon
concepts intersect, i.e. they have at least one member in common""" ;
rdfs:isDefinedBy <http://rs.tdwg.org/tcs/terms> ;
skos:inScheme <http://rs.tdwg.org/tcs/terms> . |
Beta Was this translation helpful? Give feedback.
-
|
@camwebb , sorry, I got your question wrong. The fate of a I am personally happy to define a TaxonConceptMapping (or ...Alignment) class right now (even though it is not in TCS 1) with the properties of the RDF reification vocabulary (which we do not have to define; I would have been happy with the properties of the |
Beta Was this translation helpful? Give feedback.
-
|
So, OpenBiodiv-O (https://doi.org/10.1186/s13326-017-0174-5) has the object we need (see fig. 11) and that is RDF, so I see no reason why we cannot have it. See also their fig. 10 where they use SKOS to make the equivalent statement without a Statement object in between. I think TCS should also be able to do both too, as TCS 1 could, in a fashion. While TCS 1 did not have properties as such, you could make Last time I did not want to make the changes I proposed until we discussed them, but then at the meeting there were people who would have found it helpful if I had showed what I had in mind. This time, therefore, I have made the change, but created a branch for it. You can see it in https://github.com/tdwg/tcs2/tree/taxon-concept-mapping-object/docs/tcs-terms. For the moment, I have reused the mapping properties I also have not redistributed the examples yet. That is a bit more work (so far it has mainly been copying and pasting from a previous revision in GitHub), so I want to make sure people think I am on the right track first. From the discussion above though, I would surmise that people will be happy to see the reification statements disappear. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @ghwhitbread , what about the controlled vocabulary? |
Beta Was this translation helpful? Give feedback.
-
|
I’m not convinced. This vocabulary is only a subset of the TCS 101 values (and capabilities) and it is nothing like the vocabulary from OpenBiodiv. The alignments also need to make sense taxonomically; who would say NewConcept isIncludedIn OldConcept, for instance? |
Beta Was this translation helpful? Give feedback.
-
|
Does anyone have an opinion on borrowing the SKOS mapping relations |
Beta Was this translation helpful? Give feedback.
-
|
The SKOS mapping properties were made to state alignments between concepts in different concept schemes. Is that the intention here? We use or extend the core SKOS properties for alignments within concept schemes. |
Beta Was this translation helpful? Give feedback.
-
|
I see taxonomies as concept schemes and I just wanted it to be considered. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, if you ignore the versioning or do the versioning differently, e.g., have the APC tree as a concept scheme and Taxon Concepts appear in it at some time and disappear at some time, you are indeed mapping concepts in the same concept scheme to each other. So the equivalence to SKOS properties applies only in certain circumstances or under certain models. Let's consider this considered. |
Beta Was this translation helpful? Give feedback.
-
|
We do this both ways. In response to client demand, data are exposed as SKOS, treating each tree version as a concept scheme without inter-scheme mapping. We can also view the nodes (and tips) shared across versions within a single product scheme (APC) and document alignments internally (soon). |
Beta Was this translation helpful? Give feedback.
-
|
That sounds interesting. The trees in the NSL work brilliantly for me. I think, when this (TCS 2.0.0) is done, we should look into getting some language into TCS (borrowing as much as possible from other places), so that we can deal with this in TCS as well. The trees in the NSL work brilliantly for me. Maybe we can use them as a model. |
Beta Was this translation helpful? Give feedback.
-
True, they are the 'set relationships' subset of the TCS 1 Taxon Relationship Type vocabulary and they were always going to be, as we placed other terms we kept (or we put in for now) elsewhere. The set relationships are the only ones in the TCS 1 vocabulary that are actually relationships between taxa. They are the terms of the OpenBiodiv-O RCC5Relation (apart from the intensional or ostensive bit, which we wanted to do differently). It was you who wanted to rename them back to what they were TCS 1 (and I thought you were right).
I would, as would @camwebb, and there are several examples right in the document. These are the relations that do make taxonomic sense. I do want to find a place for (at least some of) the 'traditional synonymy relationships' (cf. Berendsohn & al., 2000) as well, but they are not in TCS 1 (or they are, the TCS user guide maps them to set relationships), nor are they properly defined elsewhere, so it will have to wait till a later stage (and someone else will have to lead it). I think, also, there might be a reason these terms are not defined anywhere, and defining some of these terms will be much harder than it seems. These terms are also applied rather loose-handedly at the moment, which is something you cannot do anymore when you tie them down in a vocabulary. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I have to use Teams too often, where you cannot apply to a single comment, so I had forgotten you can do it in GitHub. This is why the above comment, and the one before, are not in the right place. |
Beta Was this translation helpful? Give feedback.
-
(Following from a short discussion at today's 2020-06-30 video call...)
In TCS1, the TDWG TaxonConcept ontology, and our draft Terms document, the only way to express the relationship between two taxon name usages (or taxon concepts) is via the creation of an instance of the
TaxonRelationshipAssertionclass. While this reification of the relationship is the only way to attach anaccordingTo(at least in a table or in RDF), it is cumbersome (see, e.g., this figure). TheaccordingTois also redundant in the case of a dataset representing a taxonomic monograph, where all such assertions are being made by a single author in a single publication. For simpler modelling of TNU relationships, I suggest that some users would value a standardized alternative in which the relationship types were themselves properties of a TNU. For example:These new properties would be added to the properties section of the TCS2 Terms document.
Beta Was this translation helpful? Give feedback.
All reactions