Question: skos:Concept and edm:TimeSpan predicates

[mcritchlow]

Questions for @ucsdlib/domm via @lsitu

Currently the skos:Concept and edm:TimeSpan classes have predicates that contain links to instances of the same class. take hasPart for example, in edm:TimeSpan.

Longshou expressed some concern with this potential nested linking of class instances, from an implementation standpoint, and that, as far as he's aware, we're not actually using these predicates.

1. Are we planning to use these predicates?
2. If not, or we don't have use cases for them now, could we possibly leave them out of the initial implementation?

[remerjohnson]

This is a good point by @lsitu. I don't recall why we have hasPart and the inverse within TimeSpan.

Maybe @arwenhutt or @MetadataDeluxe would know...

[remerjohnson]

Looking again via EDM's GitHub, I am no clearer on why certain predicates exist or their usage. So guessing they can be safely left out?

[ghost]

I think hasPart would be used within edm:TimeSpan to say something like: the 20th century hasPart 1970s (1970-1979). I don't imagine us ever using this, so I agree that we don't need to implement it hasPart or isPartOf in edm:TimeSpan

[lsitu]

Thank you all @ucsdlib/domm . Do we have any use cases for "next" that are referencing another TimeSpan at this time? For skos:Concept and edm:Agent, I see lots of predicates that are linking to the same class as well. Is it possible to simplify it and make it a little flatten with a URL instead?

[remerjohnson]

For the 'next' predicate in general, would we try to handle that through other methods? I'm trying to think of when this is crucial at the data level but coming up with nothing... Unless we wanted to be really formal and say 'Holocene' is nextInSequence for 'Pleistocene'?

[arwenhutt]

I'm confused. We DO want to be able to assert relationships between different agents, concepts, etc. But wouldn't the range be URI?

[arwenhutt]

@lsitu we've been discussing this a bit:

1. we aren't sure whether, in these cases, the range value is a short hand for "a URI for a thing which is of this class" or if it's a more literal nested record
2. we don't want to "nest" another agent, concept, etc. within/under a record of the same class
3. but we do want to be able to assert/describe relationships between "records"
4. we imagine that the relationship (predicates) would always reference a URI (object)

[lsitu]

@arwenhutt : Could we start from the simplest case that you want for edm:Agent, skos:Concept and edm:TimeSpan, and update the data model to reflect the changes so that we can implement it?

[arwenhutt]

I think starting from our minimum current requirements with a structure which allows future expansion is fine. But we still need some clarity on what the ranges in those concepts actually mean, before we could update the model to reflect that "minimum".

@lsitu can you clarify whether in the examples you're raising the range value is a short hand for "a URI for a thing which is of this class" or if it's a more literal nested record of that class?

[ghost]

Echoing @arwenhutt for clarity: @lsitu do you think that the intention skos:Concept as the Range for exactMatch was that exactMatch would be a URI and that URI would resolve to a record that used the class of skos:Concept?

[lsitu]

@GregReser : I am not sure how exactMatch is used but it could be an URL that is linking to an external record, which is a link data issue and we may not know whether it's a class of skos:Concept or not, right? @arwenhutt : Regarding your question, I think for TimeSpan should be a nested record of class TimeSpan, while for edm:Agent and Skos:Concept, with the authority records created locally, it's "a URI for a thing which is of this class" with those classes, so you haven't changed anything at all, and I think it's correct to use the class name in the data model.

[arwenhutt]

@lsitu we just met and started doing a review of the classes in question. We reviewed agent and concept, updating ranges, adding definitiion and usage guidelines, and identifying which predicates we think aren't required to meet minimum requirements and basic identified use cases. There are still some questions related to these that we'll need to figure out, usually identified in comments in the data model.

We still need to talk about timeSpan and place, which are both more complicated. I'm going to schedule another meeting tomorrow afternoon and will let you know the result of that conversation.

[mcritchlow]

Was just chatting with @remerjohnson and thought I'd drop this here.

I know we're likely going to dig into this further in the Friday meeting. But, I think we need to probably clarify our thinking on the purpose of the skos mapping properties, such as exactMatch.

From the SKOS w3c spec

The SKOS mapping properties are skos:closeMatch, skos:exactMatch, skos:broadMatch, skos:narrowMatch and skos:relatedMatch.

These properties are used to state mapping (alignment) links between SKOS concepts in different concept schemes, where the links are inherent in the meaning of the linked concepts. 

I don't think we can/should commandeer the range of those properties to include arbitrary URI's. I think if we're going to use them to relate to other skos:Concept instances, then that's all good (and as intended). But otherwise, we might need to look for either different properties or mapping choices.

[arwenhutt]

Why would we use them for arbitrary URI's?

[mcritchlow]

@arwenhutt - Arbitrary is probably the wrong way to say it. I think what I was trying to clarify was that if we use those mapping properties, they need to point to other skos:Concepts as documented. This was mostly in response to the dialog that started a few comments up

Per @lsitu 's point, I suppose, if we're going to link to authority records using a property such as exactMatch that record should dereference as a skos:Concept. If it can't, we should probably look to something like rdfs:seeAlso

[arwenhutt]

Ah. Yeah, so we are actually avoiding exactMatch for a pretty similar reason. We've updated the concept, agent, place and timeSpan categories. For matches to other authorities for the same concept, agent, place - we're recommending "closeMatch". We felt that in most cases, especially with retrospective reconciliation, it would be difficult to confidently assert an exactMatch - even when the labels are exact textual matches.

We're also recommending using "relatedMatch" for referencing external resources that aren't completely parallel (at least in type of linked resource), the use case being a wikipedia article which is a way to represent the conceptual thing/agent/place, but it's descriptively a little different then the vocabulary matches that would be referenced in closeMatch.

I agree that the item referenced by any of those links should conceptually match the item in the record itself but since we are pointing to external records, I can't imagine how we would enforce that on the machine side.

[lsitu]

@arwenhutt : We also got feed back from UCSB regarding their local authority system. I looks like theirs are fairly simple with just a label/name and a URL: https://github.com/ucsdlib/dams5-cc-pilot/issues/11#issuecomment-248382768

[mcritchlow]

The(or perhaps A) way we'd enforce on the machine side is to get the RDF graph for a given authority URI (either as an initial validation and/or during dereferencing for indexing) and look through the rdf:type assertions for a skos:Concept entry.

Here is an example, using dbpedia and LC:

So assertions using closeMatch and relatedMatch we could validate. I realize that leaves us with the potential of less semantically meaningful predicates (like rdfs:seeAlso). So I guess it comes down to how 'pure' we want to be with using those skos mapping properties.