Re: Requirements for a possible "RDF 2.0"

On Mon, Jan 18, 2010 at 6:00 PM, Pat Hayes <phayes@ihmc.us> wrote:
>
> On Jan 18, 2010, at 8:18 AM, Harry Halpin wrote:
>
>> Re adoption, basically I can't really point most hackers or
>> implementers at the RDF specs without terrifying them (yes, syntax
>> matters). A lot of them get overwhelmed - so when explaining RDF for
>> the first time, to be honest I tend to point them at TimBL's N3
>> tutorial [1] and *then* the specs.
>>
>> A simplification of the current specs is needed, with the things
>> everyone uses (i.e. named graphs) added into the spec, with things
>> like bags and list dropped. I also would like to have a decent way to
>> express ordered lists in RDF and a clearly blessed (i.e. Turtle)
>> syntax, along with JSON and Atom serializations. I think this is
>> important for the future of RDF - new apps are great, but we need more
>> programmers, and giving the specs a spring-cleaning would help.
>
> Well, you need tutorials/ introductions/ RDF-for-Dummies stuff. That is
> being written, but it s not what should be in a spec, right?


No, but the spec should allow a competent Python/C/Ruby/etc.
programmer to read it and understand RDF, and the implement compliant
software. Essentially, specs should, IMHO, be aimed at implementers,
while the tutorial stuff can be aimed at users and of course does not
need to spec.

 I am noticing that while the current RDF specs are very thorough, and
the editors deserve  lots of credit for that, they should be
simplified. For example, I know of implementers that go off and use
rdf:Alt and reification, and because they arent on swig etc., they
have no idea this is "bad practice". This common knowledge should be
noted in the specs.

The Semantic Web, unlike most other Web standards, is basically a
research project - and a far-sighted and correct one it seems! -
disguised as a standardization project, and so its not surprising that
after a number of years, some concrete lessons have been learned. I
see no reason to aim them at the spec.

Most informal specs nowdays (see say, opensocial) go through a rapid
evolution and feedback from developers phase, something that the "make
spec once and never update" policy doesnt work to well with. There is
probably a golden mean somewhere, where we can make and should make
incremental updates to most specs every 5 or so years if they are
still being used.



>
> Pat
>
>>
>> On Thu, Jan 14, 2010 at 9:43 PM, Kjetil Kjernsmo <kjetil@kjernsmo.net>
>> wrote:
>>>
>>> All,
>>>
>>> Like some others, I think the adoption problem is not solved by another
>>> spec, but by actually writing useful stuff. Still, I think there are
>>> things
>>> that should be fixed, but relatively minor things. I'm +1 on stuff like
>>> graph naming, kill bag, rec on serialisations, etc, but let me also bring
>>> forward one little thing that is of major importance: Units.
>>>
>>
>> +1. This is a major problem - one that also haunts XML Schema
>> Data-types. Jen Tennison has some excellent work in this area [1].
>> Perhaps extensible data-typing is what is needed?
>>
>> [1] http://www.w3.org/2000/10/swap/Primer.html
>> [2] http://www.jenitennison.com/datatypes/
>>
>>> There are no good ways to express the units of numbers in RDF. Yet, most
>>> numbers out there are expressed with units. You could do it with datatype
>>> URIs, but datatypes are orthogonal to units. You could do it with some
>>> hacks, people have been doing that, but it quickly gets complicated and
>>> far
>>> from ideal. We really need a simple way to express units, and ways to
>>> make
>>> it possible for agents to convert numbers between different units.
>>>
>>> Concrete example: Lets use DBPedia to find aircrafts with a certain
>>> maximum
>>> take-off-weight that can take off from airfields with a certain maximum
>>> runway length. All the data is on Wikipedia, and writing the SPARQL query
>>> should be easy (actually doing it is left as an exercise to the reader
>>> ;-)
>>> ).
>>>
>>> But it can't be done, at least not without a lot of painful hacking on
>>> the
>>> client side, partly because not all the data is in DBPedia (notably, the
>>> take-off-run when the aircraft is fully loaded i.e. at MTOW), but
>>> importantly because of the units used, see e.g.:
>>> http://dbpedia.org/page/Stockholm-Arlanda_Airport
>>> where the numbers are dimensionless, and the unit is in the property,
>>> e.g.:
>>> dbpprop:r1LengthF, while the MTOW is expressed like this:
>>> dbpprop:maxTakeoffWeightMain    "20,200 lb"@en ;
>>> for http://dbpedia.org/page/Cessna_Citation_Excel
>>>
>>> So, this is actually pretty useless. You cannot do the stuff that Linked
>>> Data should be good at with this.
>>>
>>> So, you could say that this could be done Right and Consistently,
>>> whatever
>>> Right may be, but when we, as a community (DBPedia is our community
>>> project, right) has failed to do it Right, I would blame it on that it is
>>> too hard to do Right.
>>>
>>> Not only is this important for everyday applications, it is also
>>> indispensable for most scientific applications. So, that's my main
>>> requirement.
>>>
>>> Cheers,
>>>
>>> Kjetil
>>> --
>>> Kjetil Kjernsmo
>>> kjetil@kjernsmo.net
>>> http://www.kjetil.kjernsmo.net/
>>>
>>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

Received on Wednesday, 20 January 2010 02:03:26 UTC