Re: RDF datatyping goals (action from teleconference)

On 2002-01-15 14:11, "ext Graham Klyne" <GK@NineByNine.org> wrote:

> At 09:29 AM 1/15/02 +0200, Patrick Stickler wrote:
>> 1. Regarding note 2, we should change "primitive" to "anySimpleType" to
>> coincide with the XML Schema terminology. The statement that we
> don't/won't
>> address derived types is not quite correct, as we should support all
>> instances of anySimpleType, even those that are derived, and not only
>> the built in types but also all custom defined instances of
> anySimpleType.
> 
> The terminology "Built-in" and "primitive" also comes from the schema
> document (e.g. part 2, section 3).
> 
> I'd like to seek wider consensus on the specific point you raise, but
> I've 
> added some words to the document.  (My preference is to start simple and
> 
> build up from there;  i.e. have an account for the primitive types
> first, 
> and then see if it extends cleanly to the derived types.)

Fair enough, though I expect that we'll want a solution that works with
any anySimpleType (i.e. any lexical datatype).

We need not support any of the definitional facets of XML Schema to
support any lexical anySimpleType. What matters is that anySimpleType
is a lexical datatype (has a value space and lexical space) and we
are able to unambiguously define in RDF the mapping from the lexical
space to the value space. How the value space (and lexical space) is
constrained in terms of superordinate types need not enter the picture.
 
> 
>> 2. Regarding note 6, "include" should probably be "infer", as in
>> 
>> "It should be possible to infer typing information in an RDF graph by
>> referencing an associated RDF schema."
> 
> Hmmm... "infer" carries some (logic-related) baggage that I didn't want
> to 
> invoke at this stage.
> 
> How about "indirectly incorporate typing information..."

How about 'imply', taking the DAML+OIL terminology of explicit (local)
versus implicit (global) typing?
 
> 
>> 3. Regarding note 7, the statement "One of the dimensions by which one
> can
>> categorize datatyping proposals is by whether individual values are
>> explicitly or implicitly typed" applies really to idioms, not the
> datatyping
>> scheme/model itself. Thus "proposal" should probably be changed to
> "idiom"?
> 
> Hmmm... I'm reluctant for two reasons:
> (a) this text is pretty much the desderate the DAML+OIL joint committee
> gave us, and I don't want to mess with it too much,
> (b) I think it's OK to the extent that any "proposal" could be said to
> support (i.e. allow use of) one or more "idioms".

Fair enough. Taking each proposal as a total package of model and idioms,
it is up to each proposal how modular that package is.

Agreed.
 
> 
>> 4. Regarding note 9, it may be misleading that different idiom examples
> have
>> disjunct ontologies (with namespaces specific to each idiom). This
> sidesteps
>> the issue of co-existence in a knowledge base. The role of an idiom is
> to
>> express knowledge according to a given ontology -- and is not specific
> to
>> any particular ontology.
>> 
>> Please use just 'ex:' in the examples, and if that means idioms A and B
>> interact in an undesireable fashion, then that is useful information
> for
>> evaluating the different combination of proposed idioms.
> 
> The exact point of using different names is to avoid the assertion that
> it 
> is the same name that is used in every idiom.  (I considered using
> Sergey's 
> .lex, .val and .map conventions, but did not because that implied too
> much 
> about how the idioms would be interpreted.)

But your examples suggest that no idioms can coexist. You say that
all of the idioms speak of Jenny's age, but they don't. They each
speak of a different "kind" of age.

We need to be able to evaluate all idioms and all proposals from within
the context of a single ontological space.

> I'll note that, where more than one idiom is supported by any given
> proposal, the ex*: names used may be the same or may be different for
> any 
> pair of supported idioms.

I think it's still too misleading.

I.e. it allows the S/A and S/B idioms to "appear" to coexist, but
they don't, and lots of folks may miss that.

I want to see the document achieve as full a neutrality to the
current proposals as possible, but separate namespaces is drawing
the line a bit too far out there.
 
>> Furthermore, since N3 is not the official serialization for RDF, I
> propose
>> that we use RDF/XML for all examples in formal publications. It's fine
> to
>> use N3 informally, but it is IMO impolite to expect all parties
> interested
>> in reviewing formal publications of this WG to learn N3.
> 
> Yes, OK.  As far as I'm concerned, this is an informal discussion
> document.  (Hmmm, I should probably say that somewhere.)

Agreed. It's informal -- but the audience that it supposedly is intended
for (RDF Interest) may still not have the familiarity with N3 to properly
digest the examples.

It's not a major deal, but some folks may appreciate the XML.
 
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 Tuesday, 15 January 2002 11:47:53 UTC