Re: Graph naming?

On Feb 25, 2004, at 12:10 PM, Jeremy Carroll wrote:
>
>>> rdfstore:context properties to flag each description block
>
> It's a good solution to the current situation - i.e. providing 
> compatibility with RDF/XML and providing context info, however it has 
> a number of drawbacks that should be considered if aiming at a 
> revision of RDF ....
>
> 1) The structure of the XML elements becomes significantly more 
> important, in that the rdfstore:context attribute has scope over all 
> triples generated in the XML element to which it is attached. This is 
> the same scoping as say xml:base but cannot be recovered from the 
> triples generated using the current RDF/XML rec - thus the backward 
> compatibility is merely at the level that current tools don't vomit. 
> It might be better if they did.

yes such property functions much more like an xml:base, in the sense it 
"scopes" assertions into a certain "space" - and can be overridden in 
sub-elements or sub-descriptions. But the similarity ends there - 
rdfstore:context remains/behaves as an RDF property (even if special 
for some parsers/tools) - and while "semantics" of xml:base are not 
generally being preserved (or are lost), the rdfstore:context is being 
specifically stored/represented into the RDF-storage [1]. Then the 
serializer generates "normalized" RDF/XML syntax back, grouping each 
rdf:Description block by its subject resource with its full 
provenance/naming information; each description of the "space" itself 
(e.g. rdf:Context description block in my FOAF for profile) is also 
rendered normally as RDF/XML - unless a nested context/space is needed 
- then this rule applies over and over.

the context and contextnodeID properties allows also to overrride 
"default" (current) space/context identifier with an "empty" one (aka 
back to normal RDF "triple space") if needed by either using some 
special rdfstore:EmptyContext resource value or using an empty 
contextnodeID on the element/description-block - this turns out to be 
quite handy to override descriptions into an "empty" space or your own 
local "view" of things.

so - I have to disagree on the fact it is not backward compatible on 
this aspect  (of course unless the RDF software does vomit on it :)

>
> 2) The context is handled with the open world assumption - i.e. you 
> can have any number of rdfstore:context attributes with thesame value, 
> and their effect is cumulative. I believe there may be use cases in 
> which this is not appropriate.

definitely agree that our is a sub-case of the whole "solution" (or 
problem) - but as already mentioned, this solution has shown to be 
enough to model our user requirements and application domains. And it 
will definitively need more work in the long run to really test and 
deploy it properly.

> 3) It is not clear what the intended semantics is, in many ways the 
> fact that you can translate the RDF/XML into triples which have a 
> (wrong) meaning under RDF Semantics, is a handicap.

this might be true in some sense - you have got those "spurious" 
triples to live-with - which might be too noisy for your application - 
or not ;-)

but in any case, I agree with you - we need kind of agree about the 
"semantics" of such constructs into a broader sense/definition - and 
write them b/w on paper then everybody can count on and use them.

....now me back digging into Sowa and Date books looking for some 
similar concepts/definitions, which might helpful to fit such 
constructs into the whole picture and explain it better - well not easy 
indeed - but they work! SQL views and domains are not far from our RDF 
"naming" problem but they seem not just enough at first sight - with 
RDF we suddenly have got much more general and powerful tools in our 
hands...

Yours

Alberto

[1] http://www.asemantics.net/presos/SWAD-E/SWADe-rdfstore.html

Received on Wednesday, 25 February 2004 12:18:20 UTC