> -----Original Message-----
> From: ext Roland Schwaenzl
> [mailto:[log in to unmask]]
> Sent: 16 January, 2003 13:44
> To: [log in to unmask]
> Subject: Re: rdfs:isDefinedBy revisited
>
>
> > From [log in to unmask] Thu Jan 16 11:38 MET 2003
> > X-RAL-MFrom: <[log in to unmask]>
> > X-RAL-Connect: <pat.bath.ac.uk [138.38.32.2]>
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > X-Priority: 3 (Normal)
> > X-MSMail-Priority: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> > Importance: Normal
> > Date: Thu, 16 Jan 2003 10:40:29 -0000
> > From: Pete Johnston <[log in to unmask]>
> > Subject: Re: rdfs:isDefinedBy revisited
> > To: [log in to unmask]
> > X-Spam-Status: No, hits=-0.8 required=5.0
> > tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01
> > version=2.43
> >
> > Patrick,
> >
> > Thanks for this. Yes, I remember you made a similar point
> in the thread
> > here back in May/June (but yes, it's worth reiterating, I think).
> >
> > The problem you describe (and address with your x:Vocabulary and
> > x:RDFSchema classes and x:term property) is (I think) pretty much
> > _exactly_ what motivated my initial ruminations on this
> topic, and why I
> > embarked on this hair-splitting to establish exactly what are the
> > resources we are talking about.
> >
> > i.e. I wanted to express the relationships between terms
> (in my case I
> > was specifically interested in the subset that DC calls
> elements i.e.
> > RDF properties) and "functional" sets/aggregates of those
> terms (element
> > sets, vocabularies, term sets, whatever we call them),
> where there was
> > no _necessary_ coincidence between the set of names of
> elements in one
> > "element set" and the set of names "in" an XML namespace.
> And an RDF/XML
> > representation was a different resource again. Yes, often there is a
> > one-to-one mapping but it's not necessarily so.
> >
> > So I've ended up coining classes "Schema", ElementSet" and
> a property
> > "isElementOf". It just continued to niggle me that I was introducing
> > these "local" semantics that I should avoid if possible, but I think
> > your example below clarifies to me that it is useful/necessary.
>
> The classes "Schema" "ElementSet" "isElementOf" you still
> need to declare
> in some formal fashion - an you will need a namespace for those and
> representations in whatever Schema languages ....
>
> It seems to me you just entered another round.
Well, yes, but it's not an infinitely recursive process. It stops
at the top meta-level of your model.
> > And as you say, in this application, I absolutely should
> not deploy a
> > URI which is already in use as an XML namespace name as the
> identifier
> > of one of these functional aggregates (which was a mistake I made
> > earlier!)
>
> Why not? You're using the same notation (URI) for instance, when doing
> content negotiation for language.
> You definitely in general will receive objects a "diff" will mark as
> different for "en-GB" and "en-US" - Nevertheless they are both
> retrievable from the same URI.
Well, the point was that a namespace and a vocabulary are not
(necessarily) the same thing, and if they are different things, then
one should use different URIs to denote them.
Furthermore, it is not even the case that a given vocabulary is
a superset of information. A vocabulary may only use *some* terms
which are members of a given namespace and such a representation
of that vocabulary is not a complete (and hence arguably not a valid)
representation of the namespace.
The problem IMO with conneg is that there is no clear means to
request or determine if what is returned is a kind of "canonical"
representation of a resource which embodies some clear qualities
such as completeness, economy, explicitness, etc.
"Representations" are so vaguely defined that different folks
draw the line in different places as to what is a valid representation
versus a separate resource needing distinct denotation.
My advice is to err on the side of caution, particularly since
ambiguity has such significant negative impact on semantic web
applications.
Patrick
> Cheers,
> rs
>
> > Thanks again - that was very helpful.
> >
> > Pete
> >
> > > -----Original Message-----
> > > From: DCMI Architecture Group
> > > [mailto:[log in to unmask]] On Behalf Of
> Patrick Stickler
> > > Sent: 16 January 2003 09:18
> > > To: [log in to unmask]
> > > Subject: Re: rdfs:isDefinedBy revisited
> > >
> > >
> > > > -----Original Message-----
> > > > From: ext Pete Johnston [mailto:[log in to unmask]]
> > > > Sent: 15 January, 2003 16:01
> > > > To: [log in to unmask]
> > > > Subject: Re: rdfs:isDefinedBy revisited
> > > >
> > > >
> > > > ... I definitely do want to distinguish
> > > >
> > > > - a set of terms or names (1 or 2) identified by a URI e.g.
> > > > http://purl.org/dc/elements/1.1/
> > >
> > > Fair enough. This would equate to a functional vocabulary, as
> > > outlined below, but I'd use a different URI from that used as
> > > the XML namespace URI.
> > >
> > > > - a particular representation of that set of terms
> (e.g. an RDF/XML
> > > > document) which happens to be Web retrievable using that
> > > same URI (3)
> > >
> > > If the URI denotes a vocabulary, then an RDF/XML
> > > representation of the definition of that vocabulary would be
> > > appropriate.
> > >
> > > --
> > >
> > > This may be obvious and I probably don't need to mention it,
> > > but the object of rdfs:isDefinedBy need not be the thing
> > > denoted by the XML namespace URI. In fact, if one has several
> > > different schemas (XML Schema, RDFS, RELAXNG, OWL, XTM, etc.)
> > > not to mention multiple instances of a given encoding (e.g.
> > > separate RDFS instances defining labels and descriptions for
> > > each language) which all provide definition of a term, then
> > > each may be identified by an rdfs:isDefinedBy statement.
> > >
> > > I.e., there is no requirement for the pattern
> > >
> > > XXX:term rdfs:isDefinedBy XXX
> > >
> > > and IMO it should be avoided.
> > >
> > > A given functional vocabulary, such as DC, need not be
> > > constrained to terms grounded in only one namespace, and the
> > > resource defining that vocabulary need not equate to the
> > > resource(s) defining the individual terms. There can thus be
> > > multiple functional vocabularies which share common terms and
> > > the definition of the vocabulary is not dictated by the
> > > definition of the terms. A good example of this is PRISM,
> > > which is a functional vocabulary which includes terms from
> > > other functional vocabularies (e.g. DC) as well as defining
> > > terms of its own. And of course, the identity of a given
> vocabulary
> > > is not the same as a particular namespace (and in the case
> > > of vocabularies with terms from multiple namespaces, cannot
> > > be the same), and hence vocabularies should have a distinct
> > > URI from any XML namespaces.
> > >
> > > IMO a vocabulary equates to a DCMI namespace.
> > >
> > > Thus, the formal definition of a vocabulary such as DC or
> > > PRISM could be organized thus (this is how we do it at Nokia):
> > >
> > > RDF instance a:S
> > > [
> > > a:S rdf:type x:RDFSchema .
> > > a:V rdf:type x:Vocabulary .
> > > a:V x:term g:t1 .
> > > a:V x:term g:t2 .
> > > a:V x:vocabulary b:V .
> > > a:V rdfs:isDefinedBy a:S .
> > > ]
> > >
> > > RDF instance g:S
> > > [
> > > g:S rdf:type x:RDFSchema .
> > > g:t1 rdf:type rdf:Property .
> > > g:t1 rdfs:label "Term G1" .
> > > g:t1 rdfs:isDefinedBy g:S .
> > > g:t2 rdf:type rdf:Property .
> > > g:t2 rdfs:label "Term G2" .
> > > g:t2 rdfs:isDefinedBy g:S .
> > > ]
> > >
> > > RDF instance b:S
> > > [
> > > b:S rdf:type x:RDFSchema .
> > > b:V rdf:type x:Vocabulary .
> > > b:V x:term h:t1 .
> > > b:V x:term k:t1 .
> > > h:t1 rdf:type rdf:Property .
> > > h:t1 rdfs:label "Term H1" .
> > > h:t1 rdfs:isDefinedBy b:S .
> > > k:t1 rdf:type rdf:Property .
> > > k:t1 rdfs:label "Term K1" .
> > > k:t1 rdfs:isDefinedBy b:S .
> > > ]
> > >
> > > Here we have 6 different XML namespaces, two vocabularies,
> > > and four terms, all defined in three RDF resources. Each
> > > vocabulary defines the terms and/or subvocabularies it
> > > includes. The first
> > > vocabulary subsumes all the terms in the second vocabulary.
> > > Insofar as the definition of the vocabularies is concerned,
> > > the XML namespaces used by the individual terms is
> > > irrelevant. The RDF resource g:S defines terms that are all
> > > grounded in the same vocabulary. The RDF resource b:S not
> > > only defines terms grounded in different namespaces but a
> > > vocabulary as
> > > well.
> > >
> > > So, hopefully it is clear that there is no fixed relation
> > > between vocabularies, XML namespaces and schemas, and in fact
> > > it is far more flexible and scalable to avoid any ambiguity
> > > in this regard by presuming that the XML namespace denotes
> > > any particular schema or vocabulary.
> > >
> > > XML namespace != vocabulary != model != schema instance
> > >
> > > Just thought I'd reassert those points...
> > >
> > > Cheers,
> > >
> > > Patrick
> > >
> >
> >
>
>
|