Re: Proposal for abstract syntax representation of inline literals (was Re: weekly call for agenda items)

At 16:56 12/09/2002 +0300, Patrick Stickler wrote:

[...]


>What about round-tripping? Does the application then just choose
>any suitable datatype and lexical representation as it likes,
>rather than the original pair it recieved? What if the RDF/XML
>is being returned to the system it originated from, and a
>datatype that is not recognized or supported by the originating
>system is used?

This is a good point Patrick and seems like a pretty general question, 
independent of our choice of abstract syntax.  If an application is 
serializing a graph for transmission to another application, how does it 
choose what datatype representation to use.  There are two assumptions in 
Patrick's statement here that I'm not sure are valid:

   o  that all information in a model will have been de-serialized from 
some serialization with specific datatypes used
   o  that an application receiving information represented as rdf/xml will 
understand the same set of datatypes as the one that provided the 
information in the first place.

We could help to make the second of these true with some strong words of 
encouragement to use particular datatypes, e.g. xml/schema.

[[When serializing an RDF graph, the use of xml/schema datatypes is 
recommended for representing datatype values where the datatype 
capabilities of the receiving system are not known.]]

How would folks feel about such a strong endorsement of schema datatypes?

[...]


>I believe that having values as labels in the abstact graph will
>introduce portability and interoperability problems between
>applications as well as misunderstandings and conflict between
>application developers insofar as different applications/platforms
>are able to natively interpret and represent different sets of
>datatyped literals.

Would you like an action to analyze this issue and document those problems 
in more concrete terms.

Brian

Received on Thursday, 12 September 2002 11:14:53 UTC