Re: Alternatives to containers/collections (was Re: Requirements for a possible "RDF 2.0")

On Jan 15, 2010, at 4:11 PM, Sampo Syreeni wrote:

> On 2010-01-15, Pat Hayes wrote:
>
>> Well, simple rules are sometimes good guides to behavior. I take it  
>> that you would prefer the much more complicated advice, to let it  
>> all hang out.
>
> As for me, I'd make it straight. What do we want from the standard?  
> Spell it out loud, now, like we should have done when we set out  
> with RDF in the first place. If the full expectation had been  
> spilled out at the outset, none of this would be taking place now.

It's not that simple. I wasn't there are the very beginning, but  
certainly quite early on, and the general idea and intended purpose of  
RDF were pretty clear, and universally accepted within the WG. And the  
semantics were very clear from the beginning. We weren't in a confused  
muddle or anything like that. But the devil, as they say, is in the  
details.

> So spill out the proper semantics you want, and be content with the  
> fact that they might be shot out of the sky later on. If so, they  
> weren't mature enough to be standardized just yet. No, don't expect  
> them to be fleshed out in debate; either they're set enough to be  
> standardized as they are, or they will have to wait out for the next  
> round, in a few years time.

The semantics of RDF, as defined in the spec, are about as "standard"  
as you could wish for. They are based on ideas which have been  
textbook stuff since the 1930s. If anything, we may have erred by not  
being more imaginative, IMO.

Part of our problem here is that we aren't consolidating an existing  
body of expertise. Rather, we are in the strange position of needing  
to define the standard to be used in a new technology which cannot  
even come into existence until the standard is created and widely  
accepted. Maybe we shouldn't refer to them as 'standards'.

One sense of 'standard' is a distinctive flag flown by an army when  
moving forward into battle, which might be the sense we should all  
bear in mind.

Pat

> I don't think any other approach can really a) guarantee a  
> reasonably stable environment in which useful applications can be  
> built without continuous "standards" changes mucking up the effort,  
> or b) guarantee even a coherent, scientifically well-founded  
> standard to begin with.
>
>> If everyone MAY use one of three syntaxes, and it says so in the  
>> spec, then every engine is OBLIGED to be able to process all three  
>> of them.
>
> Just so. And then, you *aren't* obliged to process *any* syntax  
> which would countermand the standard. Usually IETF documents are  
> also worded in a way that precludes but one option, in either  
> particular case, if any. And in any case, all options are *always*  
> compatible -- in our case that would mean that any options we give  
> must always be semantically compatible as well. There should never  
> be any amgiguity as to what the semantics of the protocol or the  
> data representation are, even if the level of abstraction might vary.
> -- 
> Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front
> +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
>

------------------------------------------------------------
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 Saturday, 16 January 2010 00:47:21 UTC