W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2001

RE: Multi occurrences of the same predicate to the same object

From: Bill dehOra <BdehOra@interx.com>
Date: Thu, 18 Jan 2001 10:18:14 -0000
Message-ID: <23CF4BF2C499D411907E00508BDC95E131F872@ntmews_01.interx.com>
To: "'Alex Kuijper'" <A.Kuijper@InfoRay.NL>, www-rdf-interest@w3.org

> I have a question about multi occurrences of the same 
> predicate to the same
> object 
> (resource or literal). RDF syntax does not say anything about that. 
> [...]
> How should a RDF parser handle this? Should the multi 
> occurrences be added
> to the graph or skipped? 

A parser shouldn't handle this, a parser handles syntax (at a glance this is
syntactically legal RDF). However it might be semantic nonsense in a domain
of discourse. 

Traditionally this issue of domain specific nonsense belongs at either end
of an RDF transport. So if I had a data model or schema which specified that
a resource should have one and only one given predicate, then a validating
process can be built to trap such an infraction and/or prevent such an
infraction being passed to a serialiser in the first case (well, I can
dream). So (and deserialisation realistically implies parsing xml):

App [SCP] -> rdfserializer -> on the wire -> rdfdeserializer -> [SCP] App2

SCP stands for "semantic checkpoint", which is where you're traditionally
looking for semantic nonsense, i.e. the semantics are held in endpoint
"codecs" that were built and agreed upon out of band. 

I think some folk here would suggest that it's possible to logically (which
is not to say actually) tunnel further rdf that would semantically validate
the above rdf, i.e. keep as much of the semantics as possible in band and
make the endpoints less brittle and highly decoupled. So your codecs I guess
morph into general purpose evaluators of utterances. I have an imagining
that, architecturally, this is part of what it means to have a semantic web,
but I've never heard it put as such. Any semantic web visionaries care to


Bill de hÓra  :  InterX  :  bdehora@interx.com
Received on Thursday, 18 January 2001 05:19:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:34 UTC