Re: a simpler form of rdf xml

On 14 Jan 2005, at 16:37, Josh Sled wrote:
> 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].

Well why do people think they need to associate DTDs, or schemas,
or other fancy things with xml and that would be ok, but ontologies
would not be ok?

My xml to graph transformation should give you exactly what you you
know if you know noting about the meaning of the elements or attributes.

Now of course you could add already well understood attribute value
pairs into your xml such as rdf:resource="" or rdf:about to enable
parsers that are aware of that ontology to do their graph 
transformations.
But you have not removed the need for the ontology, you have just
assumed its existence and hardcoded it.

>> (This is nice because it clears up the xml a lot)
>
> At a [too-]large expense of the implementation, I feel.

That is an orthogonal issue. You cannot escape the fact that whatever
elements or attributes you add to your xml are in the same category
as any other element or attribute. They need an ontology to be
understood. You just want to hardcode a particular set,
the rdf/xml people another one.

>> 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.

my weird feeling is that what I have described is what underlies 
rdf/xml.
It would be really funny to show that rdf/xml could be parsed just as
well using this scheme as any other one.

> 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.

cool.


>>> 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.

Oh well that is why I would not use tools like xslt. I just map 
everything
into graph space, and consume it there, it is much easier, and much less
risky. People who want to use inappropriate tools will always have a 
hard
time. One day they will wake up to it.


> ...jsled

Received on Friday, 14 January 2005 16:28:02 UTC