Transparently merge rdf: and rdfs: namespaces

[dbooth-boston]

It is needlessly confusing to have both rdf: and rdfs: namespaces, such as rdf:type versus rdfs:subClassOf . They should be transparently merged, to allow consistent use of rdf:, but with backward compatibility for rdfs: uses.

[cyocum]

My totally subjective feeling is that there should only be one place to define logical structures. My preference is owl: but it needs to be one thing.

[namedgraph]

Have you considered how much data and software such a change would break?..

[dbooth-boston]

There would be a cost:

• Old software using old data: no change.
• Old software using new data could filter the input data to be backward compatible.
• New software using old data could be written to be backward compatible.
• New software using new data: no change.

As potential incompatibilities go, that doesn't sound too bad. But certainly we would have to weigh the cost against the benefit of making RDF easier to use.

[HughGlaser]

Yes - I confess I still sometimes look up whether something is rdf or rdfs to make sure :-(

However, is rdf(s) a good name?
If we called it something like "core" it might make more sense to people (especially in a world where we are trying to lift things away from the raw RDF).

And then...
Couldn't we simply declare owl:equivalentProperty between the rdf(s):foo and core:foo?
I've actually thought of doing that, but never tried because of worries over support for owl:equivalentProperty
(which sort of goes to the point of how easy it is to use Semantic Web if you aren't up on all the nuances going on, but that's another story!)

[cyocum]

Yes - I confess I still sometimes look up whether something is rdf or rdfs to make sure :-(

Yes, I find it jarring that there are three different ways of doing it and all of them have subtle differences. My feeling is that we should just depreciate everything other than OWL, move the things that are in the rdf/rdfs namespace into OWL3 and maybe create a new easier to use profile.

However, is rdf(s) a good name?

I do not think so.

If we called it something like "core" it might make more sense to people (especially in a world where we are trying to lift things away from the raw RDF).

And then...
Couldn't we simply declare owl:equivalentProperty between the rdf(s):foo and core:foo?
I've actually thought of doing that, but never tried because of worries over support for owl:equivalentProperty
(which sort of goes to the point of how easy it is to use Semantic Web if you aren't up on all the nuances going on, but that's another story!)

This would seem like a good idea but, as you bring up, you need to be sure that all well-known implementations work with it.

[namedgraph]

@HughGlaser nobody is asking you to memorize in which namespace an RDF term is defined. At least not more than memorizing in which Java (or python or whatever) package a class is defined. Would it make sense to suggest to Oracle to repackage classes, because you don't recall?...

If anything, this is a problem with tooling. An IDE with RDF autocomplete would solve it. Not changing namespaces which would break SemWeb URI principles, require an enormous effort, and... for what?

This, like most of EasierRDF issues, is framed to be about RDF, yet are non-issues when put in a different context. Please try to look from a different angle before suggesting to blow up the whole RDF ecosystem as the first thing.

[HughGlaser]

Thanks @namedgraph
I think what I suggested doesn't break anything.
All it needs is a suggestion to use core or whatever instead (plus support for owl:equivalentProperty).
Hence my comments - I don't want things to break if possible.
However, if we do find that there is sufficient benefit in changing RDF to make it worthwhile, then it may well be that we should tidy up this sort of thing at the same time.
Also, I do agree with you it is a tooling problem; if we had all the right tools, then it wouldn't be a problem. But if we had the right tools we wouldn't be having this activity at all - we don't, and history suggests we won't.

As for your comparison with classes - usually there are intuitive and logical reasons why things are in different classes; in the case of rdf & rdfs I don't think I have ever had that intuition - that could just be me, or it could be a strangeness that could be removed.
An accumulation of little things like this makes using a technology less efficient; and more frustrating.
And so it makes people use different technologies.
So yes, I would ask Oracle to repackage classes if they were badly packaged - and I would get the same response from them that I get from you.
For all I know, I would expect that in the early days of Java there was a lot of that happening. And that is why Java is said to be good.
If you find you that you can never remember which package things are from, there is a good chance that you will decide to use a different language, if you can.
(For php aficionados, compare parameter order for "strpos" and "in_array" - grrrrrr).
And languages do try to sort this sort of stuff out when they can.

[dbooth-boston]

@namedgraph your concerns about backward compatibility are absolutely valid, but I think it is a bit premature to worry about that yet. At this point we are really just collecting ideas, in an exploratory "what if" mode. I have no idea whether/how this would ever become part of a coherent proposal, and whether it would even involve backward compatibility issues at all. For example, if it ended up influencing the design of a higher-level RDF successor that compiles down to standard RDF 1.1, then it would be a non-issue.

One other comment: A good IDE could certainly help, but I do not agree that it would completely solve the problem. It would solve the problem only for those who use that IDE. Requiring a particular IDE would raise the entry barrier to RDF, which is exactly what we're trying to lower.

P.S. I don't think anyone is proposing to blow up the RDF ecosystem. I certainly am not. But I do want to build on what we have and what we have learned, and I absolutely do want to blow up our rigid notions of what RDF needs to be, so that we can get new, fresher ideas on the table that ultimately lead to a semantic web ecosystem that is considerably easier to use and can gain much broader uptake.

[dbooth-boston]

@HughGlaser wrote:

Couldn't we simply declare owl:equivalentProperty between the rdf(s):foo and core:foo?

Yes, and I like that idea a lot, for other reasons as well. This is tied into issue #17, because if we had a consistent, convenient way to rename URIs or define synonyms, then that mechanism could be used for this.

P.S. However, owl:equivalentProperty is not ideal for other reasons. See #17.

[awwright]

If this is an option, we may as well ask for a urn:rdf: namespace that we can move everything into. Though I know that's been brought up before, and broadly dismissed.

I think at the very least, it's worth looking into for internal usage.

[VladimirAlexiev]

There is a lot to say about Schema's sticking to one single namespace. (*)

But this proposal won't have similar impact. A typical RDF dev needs to deal with at least 10 namespaces. Sparing him 1 is of no consequence. I don't see the point.

(*) Aside: I previously thought this feature of Schema chauvinistic, and with lack of proper oversight it leads to ridiculous things like http://schema.org/Abdomen (which is not what you think it is: it's a test, really).

[chiarcos]

Actually, rdfs vs. rdf is nasty (because it is quite arbitrary) and sometimes even used incorrectly in text books. That makes things break early on for beginners. Renaming this to "core:" or whatever would be a clear cut, but not downward-compatible.

As an alternative (a bit radical, though): Can't we just duplicate all RDF concepts and properties in RDFS, so that people can just use the rdfs: namespace? The RDFS documentation needs to be changed, then, but slightly only (i.e., adding a cross-reference/owl:sameAs to the RDF spec whenever a mirrorred element occurs) , and as long as the original rdf terms are maintained (even if marked as deprecated), old data would still be upward-compatible.