STRAW POLL: Replace rdfs:range with rangeIncludes?

[tombaker]

STRAW POLL - PLEASE RESPOND TO THIS MESSAGE

About half of the issues remaining in the batch related to ISO 15836-2 have something to do with the formal RDFS ranges (and RDFS domains) assigned to properties in the /terms/ namespace. The discussion of Issue #32 to date has shown strong support for the idea of replacing all RDFS domain and range declarations with ontologically weaker declarations on the model of Schema.org domainIncludes and rangeIncludes, defined along the lines of:

• olca:rangeIncludes: "A loose coupling of a property to possible or expected values. This annotation is to be used when one does not want to enforce formally the coupling by rdfs:range or some owl:Restriction constraint."

• schema:rangeIncludes: "Relates a property to a class that constitutes (one of) the expected type(s) for values of the property."

In my reading of Issue #32, this idea is supported by Osma, Karen, Kai, Dan, Antoine, and myself with outside support from Lars (who may also speak for Jana and Sarah?) and Jakob Voß. I do not think we have heard from Joachim, Joe, and Stefanie.

Stuart suggests that we first determine whether loosening the semantics of domains and ranges would break existing systems, and Dan suggests that we collaborate on this with http://lodlaundromat.org/about/.

Makx suggests that "DCMI may want to be explicit about abandoning one of the leading principles that led to the development of dcterms alongside the original Dublin Core Metadata Element Set" and expresses concern that a retreat from the semantic commitment to formal ranges means abandoning a key argument for the added value of using DCMI metadata terms instead of, for example, Schema.org.

Were we to approve this change, we would at a minimum need to

• formulate a compelling story for the change (drawing on the excellent discussion in Issue Broken ranges? #32);
• amend or clarify the namespace policy to allow loosening of semantics (e.g., for historical lessons learned, actual usage patterns, etc);
• decide whether to use schema:rangeIncludes or coin dcam:rangeIncludes (and domainIncludes).

I would like to call for a show of hands on the following questions:

1. Do you support replacing rdfs:domain and rdfs:range with some form of domainIncludes and rangeIncludes?

2. If your answer is "yes, but only after further study", and if this study were to take longer than the current ISO process would allow, do you agree that we should reject all ISO proposals that conflict with current range (or domain) assignments?

3. Would you support the creation of domainIncludes and rangeIncludes in a DCMI namespace?

[tombaker]

1. I strongly support domainIncludes and rangeIncludes.
2. If we agree on this change in principle but set a high bar for "further study", then yes, I see no choice but to reject ISO proposals for usage comments, and the like, that conflict with the current range assignments. However, while I agree we should explore new ways of studying actual usage, I worry about the cost of delay if it means enshrining the current ranges in the ISO standard.
3. I support creating these properties in the existing http://purl.org/dc/dcam/ namespace (and not creating an entirely new DCMI namespace just for the two terms and just because dcam took its name from DCAM).

[tombaker]

I just noticed that "range" is actually defined in ISO 15836 Part 1, which is already an ISO standard, as:

class of which a value described by the term is an instance

I guess the rangeIncludes we have in mind could be defined as

class of which a value described by the term may be an instance

I'm not sure if it would be better to redefine "range", which is not actually used in ISO 15836-1, again in ISO 15836-2, or to squint hard enough and let it pass.

[osma]

1. I support domainIncludes and rangeIncludes
2. I think we can do enough study in the time we have - namely, check the LOD-a-lot data set for what kind of values (literal, URIref, bnode) are actually used with dcterms (and dc1.1) properties. It shouldn't take more than an afternoon to come up with basic statistics. But the other question for further study - the effects of the change on actual systems - I think is very difficult to answer. At most we can maybe get a partial answer from Europeana people and possibly other aggregators of DC metadata.
3. DCAM namespace sounds good to me

[sruehle]

1. I support the replacing of domain and range "from the bottom of my heart". We are using dcterms a lot (in the DDB, the KIM recommendation for "RDF-Representation of Bibliographic Data" and the ASCH model) and we have run into so many problems because of domains and ranges in the last years. And strings instead of things is not the biggest problem. It already starts with the class of the "things" when we want to use authority data from others, where the thing I link to by using dcterms:creator may not be a dcterms:Agent, but a crm:E39_Actor, or by using dcterms:type is not a skos:Concept but a gnd:AuthorityResource, etc. In that way domain and range hinder, rather than facilitate the use of dcterms. Not to talk about all the data we get without any URIs and our solutions using bnodes etc. And yes, I will highly recommend the use of URIs and will ask for it in our application profiles. But this is an application specific task and not the job of the Dublin Core vocabulary.

2. I agree with Osma. We should find a solution that fits with ISO asap. If we don't, we may have to handle two different versions of the dcterms vocabulary in the next years and I don't think anyone wants that. And I can't think of an effect on actual systems. We don't "brake" with the former rules, we only extend them. It's still be permitted to use URIs.

3. I would prefer dcam properties instead of schema, but I'm not really sure we need properties at all. Maybe a recommendation in a note or comment is sufficient.

[jneubert]

One question: Would that also apply to the range rdfs:Literal, which we have in several places (e.g., bibliographicCitation, date)?

[tombaker]

@sruehle As I see it, the impact on the ISO standard itself may not be very big. It could be as simple as replacing "Range:" - an attribute used in some of the term definitions, but only defined in words - with "RangeIncludes:" - a different attribute that would also be defined in words. As I see it, the classes pointed to would remain the same (even rdfs:Literal), with the exception of the "lumpy" classes such as LocationPeriodOrJurisdiction, which could perhaps be quietly dropped from the ISO standard and assigned a status of "deprecated" in DCMI Metadata Terms.

[sarahartmann]

1. We support domainIncludes and rangeIncludes because we do believe that it will facilitate the use of dct
2. Statistics will be good to be aware of the uasge but it is not very crucial for the decision
3. +1 for sruehle: maybe a recommendation in a note or comment is sufficient

[kcoyle]

1. yes
2. I don't think we're prepared to do this right now but I'd say it's a good time to start the process
3. yes, with some relationship to schema's "Xincludes" (sameAs? ... makes me a bit nervous, but that may be the real relationship)

[aisaac]

1. +1

2. +1 I like the idea of further research but I'm not sure statistics or impact on systems are so crucial. We already know the ranges are misused a lot (cf @sruehle 's comment) and that accordingly changing them should not impact systems too much. As a matter of fact Europeana is doing nothing with domains and ranges - and to be 150% safe we've refrained as much as possible from using the DCterms properties with such domains and ranges (we use the old DC1.1 equivalents).
   What we could do instead is to spend some time on data modeling and what we mean with the constructs that we're employing. When I read the ISO 15836 Part 1 document that @tombaker circulated, it strikes me that the definition of "range" there ("class of which a value described by the term is an instance") is not the meaning I would assign to RDFS range (which would be closer to "class of which any object of the statement using the property is an instance)...

3 +1

[jneubert]

+1

[juhahakala]

Terms range and rangeIncludes have been added to ISO draft, chapter 3.1 Terms and definitions. domainIncludes will be added once I get the definition.

[tombaker]

Moving discussion to Issue #43.