Raw

Last night I posted an email to list objecting strongly to a post by Hixie. I broke protocol. I ranted, took it personal, I basically called him a fascist, no doubt swore a bit too. But unlike many previous occasions when I've got on my high horse about stuff after a few glasses of wine, no shame this morning, I'm quite pleased I went that far, it really has got beyond pleasantries. Trying on a one-man coup as acceptable behaviour makes my sweariness pale into insignificance.

I immediately got kick-back from danbri, Bijan and the other (list gov) Ian. Danbri made the point that although Hixie might have been into eugenics in the past, he should be given the space to change. Fine - but I see no counter-arguments from those beliefs in recent times. Couple those beliefs with the evidence of a wish to take sole control... danbri quoted Godwin's law at me. In response, I have to say: if it quacks like a duck and, er, steps like a goose.

So onto the meat:

In the first paragraph, Ian associates consensus with the perjorative term "design by committee". That's just disingenous. For standards to even remotely work for all interested parties, those parties need to have some power over decisions. It will be always be a suboptimal compromise, but...well wait, he has an alternative.

One person. I wonder who he might have in mind.

He makes a fair point with "consensus amongst those who bothered to show up", but personally I believe that's a positive, the people that turn up have some kind of commitment to the matter at hand. In fact, here is he not saying "I'm prepared to show up enough that I can take this all off your hands".

Personally I also agree that "[specs] should be designed so that they end up solving real problems" - but isn't that a redundant statement? Why bother if they didn't?

I can see where he's coming from with: "I need to make sure that whatever I spec is something that the bulk of implementors want to implement, otherwise it goes nowhere." The only problem I see with that is, well the "I".

Please don't get me wrong, I do have huge respect for Hixie's brain, for technical stuff I feel C-list in comparison. But when it comes to big picture stuff, I probably have a slight advantage over many folks that spend their days with noses in code. I've seen political machinations in many other contexts, I know an attempted land grab when I see it.

But ok, assuming Hixies motivation is noble (is clearly committed, but I'm suggesting misguided) - there's an easy test. Would he be prepared to stand down and allow someone else to take that place? (noting there are plenty of capable candidates in the WHATWG)

(Comments to G+ please)

<http://hyperdata.org/Hello> a sioc:Post ;
	dc:date "2012-04-02T07:24:53.676Z" ;
	dc:title "Hello World!" ;
	sioc:content "My first post." ;
	foaf:maker [ foaf:nick "danja" ] .

schema:articleBody owl:equivalentProperty sioc:content .
schema:author owl:equivalentProperty foaf:maker .

schema:name rdfs:subPropertyOf dc:title .
schema:datePublished owl:equivalentProperty dc:issued .
schema:Article rdfs:subClassOf sioc:Item .

foaf:nick rdfs:subPropertyOf schema:additionalName .

Top-level terms

I think it would be very helpful if schema.org was a bit clearer about "top-level" terms. Right now Thing has description, name, image, url. Ok, not bad as a first pass against what's needed on the Web. But url is/should be redundant (but that's just my semweb prejudices), there's slight conflict between description and content-oriented terms like articleBody which has the intermediate node of Article. (This isn't a new phenomenon, RSS history is littered with the wreckage of content vs. description, and higher up the architectural tree it's one of the features of httpRange-14). Ok, maybe description is useful enough to leave alone, similarly name is probably reasonable to cover the top level of label, title, name. image I suppose is fair enough, a pragmatic approach to something that could easily get messy if more WebArch was brought into the picture. I guess my recommendations then would be to add a term Item (for a generic Information Resource, superclass of Article etc) and date (for a superproperty of all dates).

Automatic mapping

I haven't yet decided whether or not to use the Web vocab or schema.org versions of the terms in my internal RDF, I suppose I could even use both. But my little experience above demonstrates it's not yet obvious how to map across even with these really common terms. If the starting point was something richer, the amount of work involved could easily explode. Some kind of automation is desirable, for the benefit of someone like me in the current situation, a publisher of semantically marked-up HTML that would like their material to connect with the Linked Data Cloud, or someone writing an app that consumes data across different vocabularies. A service (or two) springs to mind: give it a term and it responds with correspondences from other vocabs, or give it a lump of data and let it offer a translation to the preferred vocab(s)/format. There are at least two approaches to implementation: SPARQL CONSTRUCT and/or RDFS/OWL inference (in both cases the use of generic superclasses/properties could be useful). The front end could offer something like the Rich Snippets Testing Tool for authors together with an open API for translation by app developers, to give a leg-up for integration/mashups. It would be nice if the good folks behind schema.org would consider throwing some resources in this direction.

See also :

• Dan Brickley at the BBC on schema.org (video)
• Danbri has moved on – should we follow?
• I, for one, welcome our new Microdata Overlords

Comments to G+ please

I posted the other day a note-to-self re. Listy Thing, though I haven't done any coding on that since I have been puzzling over one particular bit, which boils down to : how best to represent lists in RDF. Ok, there's rdfs:List and Wikipedia has quite a good definition of list, but that's not really the end of the story, there are a few practical considerations.

The conceptual model I want is just the usual thing of a finite ordered sequence of things, for sorting out my own lists: shopping, project resources and todo, bookmarks, list of people (friends & circles) etc. etc. The items in these lists will generally be either text or links (which fits nicely with RDF literals and resources)...or other lists. Ok, that just jumped into graph-land. Also the lists/items may also be lots of other things as well - like a todo list might contain tasks (yeah, got an unfinished vocab for that as well). An item may be multiple lists and so on. But the practical model I'm after is pretty much a direct reflection of HTML lists:

,
and
• to allow easy rendering/manipulation in the browser.

  One of my favourite typed-item lists of all time is (appropriately enough) Enrico Franconi's Description Logics Course. I want to be able to put things like that together really easily and - the why RDF? part - reuse the data easily.

  I've played with very similar stuff before with something I called XOW, XHTML Outlines for W6, where W6 was a simple vocab for adding just a bit of semantics to resources (addressing the questions who, why, what, when, where, how - I think it was Libby set me going down this path). Beh, loads of link rot around there, must fix - basically you could make lists of typed items in the browser, the result could be sent through XSLT to produce RDF.

  I've come at it afresh from the motivation of wanting to sort out my own lists, sod any wider problems. The tools are much better this time around, but the modelling thing is stil a quandary.

  With a bit of googling I've found some good scripts to get started and have been noodling on the HTML side - drag and drop reordering of lists, with in-place editing. Current home: live here, in github here (note - dev branch of seki). It's not far off what I reckon I need.

  Now there's the fun bit of expressing this material as pure data to stick it in a store and access via SPARQL (1.1). First pass at least I'll probably use XSLT in lots of places, the transformations should be pretty straightforward, but the SPARQL side is a bit tricky. Andy Seaborne has done a great post about lists with SPARQL Update, and as I'm using his Fuseki for storage it stands a good chance of working (heh).

  But I want to be able to muck around with these things a lot, so I'm wondering whether it might be advantageous to also 1. overlay some old-fashioned RDF container stuff on the lists as well (i.e. rdf:Seq) and even 2. simple ordinal property values, something like :

  :contains [ a :listitem; :value ; :inlist :position "43" ] .

  Dunno, may this might help with matching quirks like those Andy mentions, "the empty list isn't any RDF triples, so looking for lists isn't just looking for rdf:rest properties", (rdf:nil keeps running away!) and with SPARQL 1.1 property paths, list elements do not necessarily come out in order.

  Funnily enough, lists in RDF seem to attract a lot of caveats - there's the old stuff about how 'weak' containers are, the lovely line in the RDFS spec: "Just as a hen house may have the property that it is made of wood, that does not mean that all the hens it contains are made of wood, a property of a container is not necessarily a property of all of its members.". In the same spec, the delightful: "RDFS does not require that there be only one first element of a list-like structure, or even that a list-like structure have a first element.". But if it walks like a duck and quacks like a duck then it's made of wood, hence a witch.

  Suggestions very welcome, here's a G+ Page , see if that works for comments.

  PS. also related is the Linked Data API stuff re. lists, see e.g. listvalued_props

Mailing lists again, Facebook doesn't have a monopoly on the notion of "poke", you provide a tiny bit of impetus and get valuable results. This time Sam Ruby, one of the smartest guys I've encountered who isn't a rabid RDF fan (heh). How HTML5 process works:

[[

*) If you have a problem with the process, participate in bug reports on the process.

*) If you have a technical problem with a given change, start by identifying the technical problem.

*) If you want to be impolite on twitter or IRC, I won't be responsible for policing such.

*) Outbursts on public-html will first be dealt with privately when possible, and will be dealt with publicly when necessary.

]]

A thought in passing. When I've need to display SPARQL results in a browser I've generally either used some kind of programmatic templating (as in this blog) or XSLT on XML results - which can get clunky, but when the transformation is done, it's done. Results XML is straightforward (and I'm still rather fond of XML) but the choice of syntax is pretty arbitrary. The RDF that comes back from a CONSTRUCT is grand, that's a really nice kind of query, the data is immediately ready for reuse (it might an obsessive-compulsive thing, but DESCRIBE still feels a bit messy). I've not got around to playing with JSON results, presumably that lends itself to speedy application in most languages.

But I can't help thinking it'd be neat if SPARQL results came back directly as RDFa so by default you had something that made sense both in a browser and to an RDF agent. Is there anything you can do with a SELECT that a CONSTRUCT-to-HTML couldn't do? Is there any way the stuff could be structured to simplify templating? There's at least one results XML to HTML XSLT around somewhere, I guess that could be tweaked for experimantation.