Austin, Second on the problem with namespaces and Sparql. I spend a significant amount of code in my sem apps getting the application to manage these, rather than the querant. It's also at least one reason why I think that many ontologists tend to go to a single namespace, even where there are usually fairly strong type correlations and inheritance that can be signaled in Sparql. Manage those namespaces and prefix as type signifier usually becomes much more useful.
> We're dealing with Web Scale here. "Works for 90% of us" isn't good enough. Yup. This is my problem with HTML5 in general - while there are some benefits to creating "simplified" HTML (the biggest being partial rendering, which XML is still struggling with via the streaming APIs) the most highly touted benefit - the Aunt Gladys dictum (HTML should be simplest enough that your Aunt Gladys should be able to write it) - has always seemed specious to me. HTML5 is the only programming language I'm aware of that doesn't specifically require syntactical integrity. Not surprising, that tends to add considerably to both the browser's overhead and the likelihood of misrendering. I think this is even more true for web apps. Kurt Cagle Principle Evangelist, Semantic Technologies Avalon Consulting, LLC kurt.ca...@gmail.com, personal cag...@avalonconsult.com, business 443-837-8725 On Fri, Feb 6, 2015 at 2:30 PM, Austin William Wright <a...@bzfx.net> wrote: > > > On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr. <jackalm...@gmail.com> > wrote: > >> >> * Domain names don't mean much. For example, Dublin Core's namespace >> starts with "http://purl.org/";, which is effectively meaningless. >> > > It means that the owner of purl.org decided to allocate the namespace, as > opposed to someone else. So while it's not arbitrary, for our purposes it's > entirely opaque. > > >> * Similarly, path components often exist which are worthless and just >> lengthen the namespace for no uniquifying gain, such as the SVG >> namespace http://www.w3.org/2000/svg which contains /2000/ for some >> historical reason (it was minted in 2000, and at the time the W3C put >> the year in most urls for some reason). (Note the use of www in this >> url, compared to no www in the DC namespace. Inconsistency!) >> > > URIs are opaque, it's not really worth it to argue about how they're > designed, because their design is meaningless to everyone except the > authority that minted them. > > Every once in a while in the RDF/Semantic Web community, there's a > complaint that <http://www.w3.org/1999/02/22-rdf-syntax-ns#> is too long > to remember. Eventually the discussion realizes that it's a non issue > because, again, URIs are opaque. > > If you have to look up a URI, <http://prefix.cc/xsd> (for example) works > pretty well. > > If you type, auto-complete, copy/paste, or otherwise enter the wrong > namespace, it'll be pretty clear right off the bat that your program isn't > working. Even if that weren't the case, we have spell-checkers, why not > namespace-checkers? > > (snip) > > >> I'll stop there, though I could name a few more. All a namespace >> needs is to be of reasonable length so that it's probably unique. >> There are any number of non-insane ways to do that, but XML namespaces >> chose many of the worst options possible. >> > > I would call the namespace issue largely /resolved/ by XML. All of the > features you named exist because it adds a definite feature; e.g. the > ability to paste an SVG document directly into a document without having to > copy-paste a bunch of headers (Turtle, SPARQL has this problem; nested > namespaces are a definite *feature*!). > > XML namespaces are greatly preferable to the tag-soup problem we have with > text/html and application/json, where there's *no* namespaces whatsoever, > with *no* way to mix vocabularies, and *no* forward compatibility. > > Nothing against JSON; I maintain numerous utilities around JSON including > JSON Schema, JSON Hyper-schema, JSON-LD, and more. JSON documents are great > for what they do; XML (and other DOM serializations) documents are great > for the different task that they do, and they do namespaces. > > If nothing else, we need to support namespaces because HTML isn't the only > DOM-based hypertext technology out there. Limiting our sights to HTML would > be unfortunate. I'm not even sure how namespaces are unsupported; > namespaces exist in the DOM, even if they don't exist in the text/html > syntax. It's not terribly hard to use: > > var svgns = 'http://www.w3.org/2000/svg'; // functionally same as xmlns=, > @prefix, etc > document.getElementsByTagNameNS(svgns, 'svg'); > var e = document.createElementNS(svgns, 'rect'); > > ... this is not fundamentally different than all the DOM stuff we do for > HTML. > > We're dealing with Web Scale here. "Works for 90% of us" isn't good enough. > > Austin Wright. >
