Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transparently merge rdf: and rdfs: namespaces #52

Open
dbooth-boston opened this issue Dec 21, 2018 · 12 comments
Open

Transparently merge rdf: and rdfs: namespaces #52

dbooth-boston opened this issue Dec 21, 2018 · 12 comments
Labels
Category: language features For language features of RDF itself -- model and syntax Category: tools For RDF tools primarily-tools Tool makers should address this

Comments

@dbooth-boston
Copy link
Collaborator

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.

@dbooth-boston dbooth-boston added Category: tools For RDF tools Category: language features For language features of RDF itself -- model and syntax labels Dec 21, 2018
@dbooth-boston dbooth-boston changed the title rdf: and rdfs: namespaces should be transparently merged Merge rdf: and rdfs: namespaces transparently Dec 21, 2018
@cyocum
Copy link

cyocum commented Dec 21, 2018

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.

@dbooth-boston dbooth-boston changed the title Merge rdf: and rdfs: namespaces transparently Transparently merge rdf: and rdfs: namespaces Dec 21, 2018
@namedgraph
Copy link

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

@dbooth-boston
Copy link
Collaborator Author

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
Copy link
Collaborator

HughGlaser commented Dec 22, 2018

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
Copy link

cyocum commented Dec 22, 2018

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
Copy link

@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
Copy link
Collaborator

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
Copy link
Collaborator Author

dbooth-boston commented Dec 22, 2018

@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
Copy link
Collaborator Author

dbooth-boston commented Dec 22, 2018

@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
Copy link

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
Copy link

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).

@dbooth-boston dbooth-boston added standards Standardization should address this primarily-tools Tool makers should address this and removed standards Standardization should address this labels Mar 11, 2019
@chiarcos
Copy link

chiarcos commented Mar 4, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: language features For language features of RDF itself -- model and syntax Category: tools For RDF tools primarily-tools Tool makers should address this
Projects
None yet
Development

No branches or pull requests

7 participants