Re: Slim RDF

Pierre-Antoine CHAMPIN wrote:
> 
> Sergey Melnik wrote:
> >
> > Following the recent discussion on wrt syntax and namespaces I'd like to
> > mention the internal data model based on RDF that I'm using in my
> > research:
> >
> > Let U be the Unicode alphabet and U* the set of strings defined over U.
> > The set of entities E and the set of statements V are defined using the
> > following recursive definition:
> >
> > 1. U*xU* is subset of E (any tuple consisting of two strings is an
> > entity; the first string of the tuple is called namespace of the entity,
> > the second string is referred to as name of the entity)
> >
> > 2. ExExE is subset of V (every tuple of three entities constitutes a
> > statement)
> >
> > 3. V is subset of E (every statement is an entity)
> >
> > A subset of V is called "model". Without reification, E=U*xU* and V=E^3.
> >
> > The set of literals L is defined as L = {"urn:rdf:literal"} x U* (i.e.
> > literals are resources and can be used as subjects of statements). Other
> > primitive data types are handled similarly, e.g. ("urn:rdf:literal","5")
> > != ("urn:rdf:integer","5").
> >
> > Notice that namespaces are first-class citizens. Resource ("xyz","")
> > 'reifies' namespace "xyz", so that statements about primitive classes
> > like the class of literals are possible.
> 
> I agree it does.
> But why do you bother with { namespace, name } pairs, when the RDF model is about URIs ?
> 
> Well I know it is also about literals,
> but it seems that you boldly pushed literals in the resource pool,
> which is all right to me, I must say.
> 
> I know too that the RDF syntax in recomended in M&S is about namespaces and names,
> but this is a syntactical issue only.
> In the end, triples are only made of URIs, namespaces do not count.
> 
>  Or do they ?

Many users of the RDF API were upset about the inability to extract
namespaces from resources. Human designers like organizing the
vocabularies they create, and namespaces provide an easy (if not free)
mechanism of doing that. To exploit this mechanism, the editing tools
need to support it. Other than that, namespaces could provide a
straightforward way of dealing with primitive types, as I mentioned
above.

Thinking about the literals, it seems to me that there might have been
two key issues that prevented them from being used as subjects in the
M&S spec:

- The M&S syntax would have become even clumsier that it is now
- From the modeling perspective, you can create a lot of confusion by
making statements about literals "John" or "Boston". I think having
explicit namespaces for literals like "urn:string:John" would prevent
people from making weird statements like
"urn:string:John"--livesIn-->"urn:string:Boston" (a string lives in
another string?)

Sergey

Received on Wednesday, 21 February 2001 17:17:04 UTC