Relation to real world entities

[jpullmann]

Relation to real world entities [RRWE]

Allow for linking to or otherwise specifying real world entities, whose observation, evaluation, or control lead to the resultant Dataset.

Related use cases: Modeling relation to real world entities [ID52]

[andrea-perego]

Does it sound familiar @dr-shorthair , @rob-metalinkage ? ;)

@jpullmann , we can find some inspiration here: https://www.w3.org/TR/sdw-bp/#spatial-things-features-and-geometry

[dr-shorthair]

In Melbourne our trees have email addresses http://www.heraldsun.com.au/news/victoria/people-can-email-city-trees-and-get-response-in-melbourne-city-council-green-scheme/news-story/d75565bc5ef4804f72cdcd8226540d4d and
https://www.theatlantic.com/technology/archive/2015/07/when-you-give-a-tree-an-email-address/398210/

[akuckartz]

@dr-shorthair Those trees do not have individual mail-addresses. Their ID is transmitted as part of the subject parameter.

[makxdekkers]

Going back to the topic of the issue, could dct:subject, according to the DCMI definition "The topic of the resource" meet this requirement?

[jpullmann]

Hmm, I am not sure Makx, given the some sort of statistics data, the topic was e.g. "birth statistics", whereas the "world context" relates to the group of mothers considered (according to area, age, education level etc.)..?

[jpullmann]

Thanks, @andrea-perego, I'll evaluate the note on Spatial Data. The "world context" is often essential while searching for a particular type of data - e.g. service providers may search for status logs they maintain.

[makxdekkers]

@jpullmann As far as I know, the range of dct:subject was left undefined at DCMI to allow for anything to be a "topic of the resource" including abstract concepts but also people, events and the like. If I remember correctly, the use case was a book about a specific person. The topic of the resource would then be the person.
To limit the range of subjects to skos:Concept, DCAT defined dcat:theme as subproperty of dct:subject. In your example, I guess "birth statistics" could be modelled as a skos:Concept. If the requirement is to allow other things beyond skos:Concept to be 'topics' of datasets, I think dct:subject could serve that role -- otherwise, would you suggest another property, e.g. dcat:realWorldEntityAsTopic as a subproperty of dct:subject?

[dr-shorthair]

Also see https://github.com/w3c/dxwg/wiki/Data-aspects---semantics which is a list of predicates from other vocabularies that might be considered for use in DCAT. Some of these are intended to link to 'real world entities', and might be thought of as specializations of dct:subject.

[larsgsvensson]

For linking a real world entity to a dataset containing a description I can plug dnbt:isDescribedIn. The property is modelled as the property chain dct:description / dct:isPartOf

[makxdekkers]

@larsgsvensson Isn't the property dnbt:isDescribedIn the inverse of this issue? It seems to me that it is a property of the real world entity that points to the dataset that contains data about it.

[larsgsvensson]

@makxdekkers Yes it is. I was not trying to solve the issue but simply to supply some perepective. If you think dnbt:isDescribedIn works nicely as an inverse of what we need it should be easy to define ex:containsDescriptionOf

[andrea-perego]

@jpullmann said:

Thanks, @andrea-perego, I'll evaluate the note on Spatial Data. The "world context" is often essential while searching for a particular type of data - e.g. service providers may search for status logs they maintain.

Sorry, @jpullmann , I didn't mean to be sarcastic. The point is that the relationship between a real-world entity and its description has been a (controversial) topic for all the duration of the SDWWG.

Coming to the issue under discussion, IMO the problem is not whether the referred resource is or is not a real-world entity, but rather the type of relationship existing between the dataset and that resource.

For instance:

• "This dataset has been created with observations taken by a given sensor (or more than one)": this could be potentially be specified by using PROV (+, possibly, SOSA/SSN)
• "This dataset describes a specific spatial thing (or more than one)": this is theoretically already supported with the property used for spatial coverage (dct:spatial).
• "This dataset describes a specific temporal thing (or more than one)": this is theoretically already supported with the property used for temporal coverage (dct:temporal).
• "This dataset describes a specific thing (or more than one)": this is a more generic case, where the spatial / temporal characteristics may not be relevant. If I understand correctly, this corresponds to the general use case behind this requirement. Here a possible option could be using wdrs:describedby to link the thing to the dataset (@philarcher , what do you think?). BTW, this property has been also included in the IANA link relations register, along with its inverse (describes), defined in RFC6892,

About the use of dct:subject, I would not go that way, as dct:subject is too generic. But maybe we can be inspired by the RDF Data Cube vocabulary, where the use of dct:subject is complemented with notions as qb:dimension and qb:measure.

[davebrowning]

This potential requirement and related use case doesn't seem to be in the (current) published UCR or in the current editors draft. Marking as (potential) future work

[dr-shorthair]

Unlikely for this to be given any detailed attention in the near future.
Suggest closing to reduce the noise in the issue list.

[agreiner]

In general, I don't think we should simply close anything just because it's causing clutter. We should probably park things elsewhere for future attention if we don't think we'll get to them.

[dr-shorthair]

Fair enough. However, if there is no realistic prospect of work being done on this item, then it is effectively clutter.

[andrea-perego]

I agree with @dr-shorthair .

Besides the fact that there was no discussion on this issue since 2018, we no longer have a use case here - as pointed out by @davebrowning , it is not included in the UCR - which makes it almost impossible to exactly understand the requirements, and to proceed with the discussion.

[kcoyle]

I admit it never was clear to me what was intended, and I hoped that Jaro would explain it when we got to it. As no one else has brought it up, closing seems reasonable.

[agbeltran]

I've been trying to trace back this issue to the UCR and discussions, and couldn't find a clear link (there are meetings referring 'use cases on real world objects' (see here) but it is unclear if it relates to this issue - it would be good to hear from @jpullmann). Indeed, there seems to be no related use case in the UCR document.

However, at the moment there is no way to link a dcat:Resource to the entity it refers to and this would be an important relationship. There is dcat:theme that relates the resource to a category (the range is skos:Concept, and it is defined as a subclass of dct:subject). I note that the (non-normative) alignment to schema.org associates dcat:theme to sdo:about. But my understanding is that sdo:about is broader, and provides to link to entites, as does the term used in OBO Foundry ontologies: 'is about' term.

We had relaxed the dcat:theme's domain (see #123) - perhaps we should relax the range too (or consider other property)?

[makxdekkers]

Relaxing the range of dcat:theme, i.e. leaving it blank, removes the only thing that makes it different from dct:subject. It was introduced in DCAT2014 specifically to allow narrowing the range to skos:Concept. If there is a need to use a property that allows a reference to anything that the dataset 'is about', simply using dct:subject could do the trick. The range of dct:subject was left blank on purpose to allow expressing that the resource 'is about' persons, places, anything at all.

[agbeltran]

Thanks @makxdekkers - then it seems it would be good to add some guidance on using dct:subject and one or more examples of this use case. Also, I suggest updating the alingment of sdo:about to dct:subject rather than dcat:theme.

[kcoyle]

@agbeltran Could you give an example of what you mean by "entity" when you say:

there is no way to link a dcat:Resource to the entity it refers to

Thanks.

[makxdekkers]

@agbeltran I don't think it is wrong to associate dcat:theme with sdo:about, the only thing is that it works only one way: every object of dcat:theme is a valid object for sdo:about but not the other way around.

[makxdekkers]

@agbeltran Could you give an example of what you mean by "entity" when you say:

there is no way to link a dcat:Resource to the entity it refers to

@kcoyle As far as I understand, the 'entities' are things that are not skos:Concepts. Within DCAT, there is only dcat:theme to link to something the Dataset 'is about' but that does not allow to link to people, organisations, places, events.

[andrea-perego]

@makxdekkers said:

@agbeltran Could you give an example of what you mean by "entity" when you say:

there is no way to link a dcat:Resource to the entity it refers to

@kcoyle As far as I understand, the 'entities' are things that are not skos:Concepts. Within DCAT, there is only dcat:theme to link to something the Dataset 'is about' but that does not allow to link to people, organisations, places, events.

I think that's still too generic. We need a use case to exactly understand what the issue is about.

[dr-shorthair]

Predicates from SOSA/SSN are relevant here:

• sosa:madeBySensor
• sosa:observedProperty
• sosa:hasFeatureOfInterest

[agbeltran]

Hi, I'll think of an example of what I have in mind, but I was pointing to what @makxdekkers described. For that reason, my use case is related to the discussion in #1153 around the range for dcat:theme

[kcoyle]

@makxdekkers @agbeltran I don't think that it is strictly true that a skos:Concept cannot be a person or organization or place or .... any other thing in the real world. The SKOS Reference says:

"A SKOS concept can be viewed as an idea or notion; a unit of thought. However, what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive."

It seems to me that any Thing (e.g. Corporation) with a relationship to data can be either an actor with a role or a thing with some kind of "about" relationship. The latter would be SKOS:Concept. The former would be whatever properties you are using for Agents. Can anyone give a specific example of the relationship between a Corporation and a dataset that is NOT as an agent?

And BTW I would consider "Funder" to be an agent role. And if the data in a dataset covers, say, Berkshire County, then I would consider BC to be a subject of the dataset, and therefore a perfectly good SKOS concept. So I'm trying to imagine an example that doesn't fit into either of these buckets. Thanks!

[andrea-perego]

As there has not been discussion on this issue for nearly a month, and no progress in understanding the original requirements, I suggest we close it, and we create a new one once we have a use case.

[andrea-perego]

As there has not been discussion on this issue for nearly a month, and no progress in understanding the original requirements, I suggest we close it, and we create a new one once we have a use case.

No objections raised. Closing this issue.