dct:title rdfs:subPropertyOf rdfs:label?

[tombaker]

PROPOSALS

• dct:title rdfs:subPropertyOf rdfs:label
• dct:description rdfs:subPropertyOf rdfs:comment

[kcoyle]

Are these close enough to instead be a 'near match'?

• rdfs:label is an instance of rdf:Property that may be used to provide a human-readable version of a resource's name.

• dct: A name given to the resource.

• rdfs:comment is an instance of rdf:Property that may be used to provide a human-readable description of a resource.

• An account of the resource.

[tombaker]

@kcoyle

Are these close enough to instead be a 'near match'?

I'm not sure I follow. Are you suggesting that subPropertyOf is too strong? And by "near match" do you mean skos:closeMatch?

[kcoyle]

@tombaker Just looking at the definitions, dct:title does not seem to narrow rdfs:label - they appear to be at the same level of abstraction. Ditto dct:description and rdfs:comment. In practice I think they could be used interchangeably without changing the semantics of the statement.

Is there a practice use case for defining them as sub-properties? I can imagine that connecting DCTerms to RDF might be a way to make sure that DCTerms are integrated into the linked open data world, but I think that's a bigger discussion than these two properties.

[tombaker]

@kcoyle If you do think they are equivalent, I'm not sure what you mean by "near match", which sounds weaker than full equivalence.

One can directly assert that two properties are equivalent (A owl:equivalentProperty B). If this is what you mean, then this would be the strongest way to assert it and applications could reliably treat them as interchangeable.

Saying that one is a subproperty of the other would be a more cautious thing to assert though, strictly speaking, it would not logically mean that one is necessarily narrower than the other. Two properties could be subproperties of each other (A rdfs:subPropertyOf B, B rdfs:subPropertyOf A) which would be semantically equivalent to saying that the properties are equivalent.

One could say A skos:closeMatch B or A skos:exactMatch B but applications would not reliably treat them as usable interchangeably.

[Edited response. On re-reading, I take your point to be that relating RDF properties in DCTerms to RDF properties in RDF itself raises broader questions about the roles of the two vocabularies in the LOD world...?]

[kcoyle]

@kcoyle If you do think they are equivalent, I'm not sure what you mean by "near match", which sounds weaker than full equivalence.

I'm always wary of "exact match" - also, if they are a true exact match, one begins to wonder why both exist. But I do think they are at the same level of semantic abstraction.

Saying that one is a subproperty of the other would be a more cautious thing to assert though, strictly speaking, it would not logically mean that one is necessarily narrower than the other. Two properties could be subproperties of each other (A rdfs:subPropertyOf B, B rdfs:subPropertyOf A) which would be semantically equivalent to saying that the properties are equivalent.

To me, subproperty is indeed narrower. That's what "sub" means. If they are semantically equivalent there is a specific way to declare that. But really the question is "what is the use case here?" Why should dct:description be a subproperty of rdfs:comment? There may be reasons relating to searching, which (I believe) can be set to retrieve values of a property and all of its subproperties. But that's all I can think of.

So that's my main question here: what is the use case? A specific use case could override my concern about the details of their semantics for some practical gain.

[tombaker]

@kcoyle

To me, subproperty is indeed narrower. That's what "sub" means.

Informally speaking, I see your point, though I do not believe that logically speaking it MUST be "narrower" in meaning.

[tombaker]

@kcoyle

A specific use case could override my concern

Given

A dct:title B

Infer

A rdfs:label B

for use in systems that expect to see things "labeled" (and not "titled").

[kcoyle]

Yes, that is the use case I was thinking of. So now my question is: are there other DC terms that could be subclassed to RDFS terms? It seems to me that a general run through of the terms list would be in order. After all, there are terms like dct:abstract that might also benefit from being subclassed to rdfs:comment. Are there any classes that should be explicitly subclassed to an RDFS class? As defined, could any classes be inferred to be rdfs:Resource?

Perhaps you've done this thinking already, and I, for one, would benefit from your thoughts on this.

Another question is whether any of the DC Terms should be related to other vocabularies (e.g. schema.org). My immediate feeling is that we want to keep DC as unencumbered as possible and linking directly to other vocabularies becomes a morass. RDF is stable and foundational, so relationships to RDF classes and properties is a safe bet.

[niklasl]

Yes, that is the use case I was thinking of. So now my question is: are there other DC terms that could be subclassed to RDFS terms? It seems to me that a general run through of the terms list would be in order. After all, there are terms like dct:abstract that might also benefit from being subclassed to rdfs:comment.

I agree!

There might not be many more properties that are simply comments though, unless we want to reduce particular facts (such as dates, or linked resources) to "just comments". That probably wouldn't be comprehensible without some mechanism for generating strings to clarify the comment though, which itself is intractable due to the need for (human) language specific constructs (and of course string generation is beyond semantic mappings, so this isn't even an option). As for links, one might think rdfs:seeAlso is usable as a superproperty of e.g. dct:relation, but actually I think the latter is more general. For one, rdfs:seeAlso is in practise sometimes used as a sort of directive to "follow for more RDF facts" (which is fair given its definition as "Further information about the subject resource.").

Are there any classes that should be explicitly subclassed to an RDFS class? As defined, could any classes be inferred to be rdfs:Resource?

The domain of rdf:type is actually rdfs:Resource (wihch is also defined as "The class resource, everything."), so that should formally be the base class of any class. I would bet that any RDF(S)-based systems implicitly assumes that though, and I've rarely seen it asserted explicitly, apart from in the RDF, RDFS and OWL vocabularies themselves.

(The OWL RDF-based semantics goes further, though I admit I haven't digested all of it. I see is that it qoutes rdfs:Resource rdfs:subClassOf owl:Thing as a fact, which oddly enough I cannot find in neither RDFS not OWL. Anyway, OWL particulars are probably beside the point here.)

Another question is whether any of the DC Terms should be related to other vocabularies (e.g. schema.org). My immediate feeling is that we want to keep DC as unencumbered as possible and linking directly to other vocabularies becomes a morass. RDF is stable and foundational, so relationships to RDF classes and properties is a safe bet.

Very much agreed! In fact, I would actually prefer some more mappings from Schema.org to DC.