Re: PD datatyping doc plans

On 2002-01-11 16:21, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com> wrote:

> 
> 
> Hi Patrick,
> 
> note I've moved off-list, but copying to www-archive.
> This allows the conversion to be public domain but not in-your-face for
> the
> rest of the group.

Sounds good.

> Assuming the telecon OKs the plan we've just agreed, I suggest we
> propose
> that we do our work off-list in this way. This should help reduce RDF
> Core
> bandwidth utilisation.
> 
> I like your pictures, I think they are really helpful.

Nice to hear.

> I think we should decide which horse to back and forget the others for
> now.

Yes. P and D.

> My reckoning is that S is leading the race, and PL is in the race, and
> both
> are different from the sort of solutions we have been in favour of.

Well, S does seem to be leading in the WG, but I'm not so sure
as far as the broader RDF community.

> For me, the race will be won on rdf-interest (not rdf-core), hence the
> familiarity of the PD proposal is IMO the key.

Quite so, and the issue of backwards compatability and machinery
I think will kill S when folks have PD to compare it to.

> So I suggest restricting our write-up to PD, and forgetting, for now, U
> and
> P++.

Agreed.
 
> Any thoughts?

I plan to take Sergey's document and hack it to read the way I think
it should, for only P and D, based on the "pairing" model.
 
> On the maths ...
> 
> Your suggested framework ...
> 
> [[[[[
> 
> 1. Take up to section 4.1 as a starting point (rework section 3 and
>  remove sections 4.2 onwards, including section 5).
> 
> 2. Add math in or following section 4.1 that states that for any pairing
> 
>      (lexical_form, data_type_URIref)
> 
>  there is one and only one mapping
> 
>      (lexical_form, data_value)
> 
>  between the lexical space and value space of that data type.
> 
> Surely the math for this is straightforward (I wish I could provide it).
> 
> 3. Add final sections detailing the idioms P and D, how they define such
>  pairings of lexical form and data type.
> 
> ]]]]]]]
> 
> I started thinking about this and got a bit of nervous.
> 
> So far, we have decided not to have a processing model for RDF: step 3
> above
> looks like creeping towards one, and overall this looks like an extra
> layer
> in our analysis.

Hmmmm... I'll have to think about that, but it doesn't seem
like a processing model the way I normally think of processing
models.

There is no manipulation of the graph, nor any ordering issues.

But we should definitely clarify that, if only to put some
pre-emptive discussion about it.
 
> I am beginning to see the attraction of trying to do it all in the model
> theory, which, as far as I understand, Pat made a stab at in:
> 
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0011.html

I'll have a look to refresh my memory. I'm sure I read it.

> "Datatypes and MT"
> 
> I am beginning to feel that I need to bite the bullet and build on top
> of
> Pat's work and actually do some model theory.
> 
> Then your diagrams and some text would be the informal part, and we
> simply
> wouldn't have the intermediate level math that would actually be useful
> to
> an implementor!

The "pairing" model itself should absolutely be defined as part of
the MT. It was only the idioms that would be left out of the MT. But
perhaps the idioms also need to be in the MT, but modularly, as a
layer on top of the pairing model, so we retain the insulation of
the core data typing model from changes/evolution of idioms.

I.e., define the math for each idiom separately, on top of the common
pairing model.

> My understanding is the MT route that we have taken overall is a
> decision to
> leave implementation to implementators and to prioritise being clear
> over
> being at the right level for implementators.

Fair enough.

> I am flying out to the WebOnt F2F this weekend, I will try and have a
> stab
> at PD model theory on the plane. ("stab" is perhaps an unfortunate turn
> of
> phrase).

OK. I will also take a stab next week on my reworking of Sergey's
document, most of which is golden.

Cheers,

Patrick 

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Friday, 11 January 2002 10:13:24 UTC