Re: a simpler form of rdf xml

On Fri, 2005-01-14 at 09:10, Henry Story wrote:

> And in the procedure I am describing there is no need for the  
> rdf:aListOf
> to appear directly in the xml. It sufficed that it be found in the  
> ontology
> in a statement saying that foo is a relation onto an object that is an
> ordered list.

There are two very different and valid things to represent:

* repeated properties [N3/TTL's comma operator].
* collections

It only makes sense to have some description of which is being
represented immediatley in-band, so no ontology needs to be consulted,
or even to exist [in a written-down form].

> (This is nice because it clears up the xml a lot)

At a [too-]large expense of the implementation, I feel.



> For me that is easy. I find that information in the ontology. But if
> people want to be explicit they can always use rdf:type="sometype"
>   or
>     <rdf:type>http://example.com/sometype</rdf:type>
>     <rdf:type>http://example.com/someOtherType/rdf:type>

'rdf:type' would work, but I intentionally wrote 'is:a' for
[english-]language readability reasons ... marketing reasons, really.  

As well, a new namespace is desired in order to distinguish this format
from RDF/XML.

But, yes, the desire is to make the typing optional-though-possible.  I
find my scribbled N3 consists of many more untyped blank nodes; the
typing is implicit [made explicit via ontology], and that works fine.



> > Oh yeah, and there's no option to put anything in attributes.  It's all
> > in elements, except as per above.
> 
> I think my system works well with attributes? No?

If I say to you, "here's a URL to my FOAF in RDF/XML: <...>", one
problem that comes up when you try to consume it using non-RDF tools --
especially in XPath [read: XSLT] -- is that you don't have any assurance
about where the data is.  Is it in an attribute or in an element?  Since
the method of indexing @tributes is different from <elements>, you thus
either have to write all your selectors twice, or normalize the document
beforehand.  Both suck.  The no-data-in-attributes constraint is
intended to help make the world a less variable place for consumers. 
Consumers are the vast majority of the population.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`

Received on Friday, 14 January 2005 15:35:15 UTC