W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2001

Re: layering RDFS in the MT [was: New RDF model theory]

From: pat hayes <phayes@ai.uwf.edu>
Date: Mon, 27 Aug 2001 11:26:29 -0700
Message-Id: <v04210102b7b0403f4d94@[]>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org
>Dan Connolly wrote:
> > pat hayes wrote:
> > | <comment> When considering RDFS  we will require interpretations
> > | to have extra structure. </comment>
> >
> > I'd rather not take that approach. I'd rather that the model
> > theory were a model theory for all of RDF, no more, and no less.
> > I don't want to give the impression that folks should tinker
> > with the core model theory when they introduce new vocabulary.
> >
> > New vocabularies should just be specified as constraints
> > on the core interpretation structure, not changes to it.
> >
> > | in particujlar, the notion of a 'class', so we will need to
> > | assume that the universe of
> > | interpretations contains classes as elements.
> >
> > Why? It seems to me that IEXT(rdf:type) completely captures
> > the notion of 'class'. Anything we want to say about 'class'
> > can be said by way of IEXT(rdf:type), no?
> >
> > | 5. A subset IC of IR, containing classes
> >
> > | 6.  A mapping ICEXT  from IC to  the powerset of (IR union LV) ,
> > | ie the set of subsets of elements
> > | of IR or  XL.
> >
> > ICEXT(c) is just the set { x: <x,c> \in IEXT(rdf:type) }, no?
> > an IC is (at least) the set { y: exists x where <x,y> \in IEXT(rdf:type)
> > }
> > right?
> >
> > yup... you say as much later in the document:
> >
> > | >> <x,y> is in IEXT(I(rdf:type)) iff x is in ICEXT(y)
> >
> >
>I was initially expecting Dan's approach, but I think that it rapidly
>would get untidy. Even "the set { x: <x,c> \in IEXT(rdf:type) }" seems
>more obscure than Pat's way.

I see this as more a matter of textual emphasis than actual formal 
content. Ive rewritten the text with Dan's emphasis, which I hope 
will satisfy everyone. Latest version coming later today.

>It also seems important to be able to talk about the base graph model
>separately from schema performance. I see it as completely legitimate to
>have an Ntriple document that does not conform to RDF schema; and it
>does conform to something simpler (i.e. the model in the first half of
>Pat's document).
>I think the two points of view should be joined at a higher level.
>Taking Pat's document as defining an RDF M&S interpretation (I,IEXT)
>and an RDF Schema interpretation (I, IEXT, ICEXT ) [omitting reification
>and containers for now].
>I would go for something like:-
>    "A graph conforms to RDF Schema if every RDF M&S interpretation
>    of the graph can be extended to an RDF Schema interpretation."
>We can then link this in with schema definitions by noting that a graph
>g conforms to a specific schema defined by a graph s if g union s
>conforms to RDF Schema.

Yes, this is pretty much how I was planning to do it also in my 
rewrite. It means that graphs have to be potentially infinite, but 
that seems OK in principle.

>I agree with Sergey that we need to leave a wide open back door. This
>back door is used in reification, containers and daml.
>It could say that there may be schemas which are not defined by graphs,
>but these are expected to define interpretations that extend RDF Schema
>interpretations, and a graph conforms to such a schema if every RDF M&S
>interpretation of the graph can be extended to such a schema satisfying

Very pretty, thanks for the suggestion.

Pat Hayes

(650)859 6569 w
(650)494 3973 h (until September)
Received on Monday, 27 August 2001 14:25:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:03 UTC