The point I was trying to make was that they'd tied the schema into

their application based on generated code, binding the specific use of

the message contents into an object which captured those semantics in

that context.




... then yeah, you could probably describe

your UI or even other parts of your application using RDF or something similar. I don't think it would be that simple, though.




I don't think it would be that simple either. But look at the first quote. This is what is commonly done:- 

binding the *specific* use of the message contents into an object which captured .., semantics ...

If you know you just care about the data, then maybe no big deal But if
the semantics change and you *do* care about that, just imagine a few
simple rules, for instance validation rules that are determined by how
other fields have been filled out, e.g. whether they have been filled
and the type, would create enough meta information to get interesting.
Or the common place operation of whether the contents of one field is
added to another or multiplied. Simple rules that become more complex
in aggregate and which one may wish to be able to change. I have worked
on such a validation engine and the problem I identified was the way in
which every rule action (built in hivemind - java plus xml deployment descriptor)
pointed to a different unique class that really could have been broken
down into a semantic description plus a generic type, leaving far fewer
classes to contend with. The path to the class would be via its
semantic description which would determine the object plus attributes
being quieried or modified. It might be xpath like, but with a
conditional (if this field comes after that field), but obviously this
allows for far richer possibilities (the user has the option of
expanding the number of text field inputs to suit their needs, I do: if
the user has filled in over six fields then the result is of type
green, otherwise it is of type blue and so on. Type blue process
differently to type green. And yes I do imagine it being implemented in
SPARQL or such, because some of these "paths" are queries of incoming
data, but all of these "paths" would have to be available to query the
data once it is stored.) This way the semantic framework and the schema
description of data would evolve separately. I believe they shouldn't
interfere with each other. Storage issues might become moot as well
since there would have to be persistence through an RDF layer.

Just my thoughts.

Adam

 

On 01/03/06, Andrew S. Townley <andrew.townley@b...> wrote:

Warning:  it's late, so this may not completely make sense, but I won't
have much of a chance to get to it tomorrow.

On Tue, 2006-02-28 at 23:58, adasal wrote:
> So, putting this together with
>

>         I won't even mention the time canonical schemas were modified
>         in-house
>         by one of our partners to add "missing" field length
>         validation and then
>         the ensuing dismay when we tried to give them new ones that

>         were
>         structurally equivalent (without starting this argument ;),
>         but in which
>         the namespace had been altered slightly, and, of course were
>         again

>         "missing" the field sizes.  Ok, I mentioned it.
>
> this
>          We use markup over delimited ASCII
>          because we want to put more semantic hints as to the

>         producer's
>          intent.   If we want stronger hints, we go
>          to a language like RDF to provide stronger linking among the
>         signs.
>          If we want to send our intent and ensure

>          it can't be misinterpreted
>
> are you saying that a possible solution to the problem of evolving
> schemas is  the use of meta data?
> This seems so obvious, and yet, in practice it is not being done

> apart, I suppose, from where it has to be, when the schema repository
> is sufficiently large for people to think seriously about how it is
> handled. In other words, it is not being done in everyday development

> AFAIK. Moreover, in themselves, this is what RDF OWL and other
> semantic languages are, richly self describing, but they seem not to
> be used just for that, whereas I see it as a first step towards more

> ubiquitous use. I'm sure I have missed something (several things) but,
> to be clear, what I mean is the situation where the producer just
> means to describe fields in a document, their type, relationship to

> one another and so on, while the consumer can take this description
> and seperate it from any particular set of data it wraps, that is
> compute on the description independantly from the data it contains. I

> guess, use RDF to do RDF. I think I understand that this is what is
> done. Usually the referant is a resource, for instance the often cited
> example of a song with references to composer, and album art. But I

> mean references to a class "text field" with various attributes. This
> would make schema manipulation and usage operate on a completely
> different footing to how it does within the confines of XML/XML

> Schema.
> Adam

Maybe.  Like most things, it depends on the context.  What I was trying
to illustrate with the example you quoted was that, in this case, the
semantics of the data were things that don't have logical

limits--practical ones, perhaps, but if you specify a person's name as 1
or 100 characters, that just changes the representation, not what it
means.  It's still their name.  Our partners were trying to make their

lives easier when attempting to stuff the content from the document into
a database.  Just because I wouldn't do it that way doesn't mean what
they did is "wrong", it just means you have to deal with the

consequences of your decisions.

The point I was trying to make was that they'd tied the schema into
their application based on generated code, binding the specific use of
the message contents into an object which captured those semantics in

that context.  The fact they changed the schema we gave them is a
slightly different issue, and only tangentially relevant to the main
point--if at all.

I haven't seen their code, so I don't know if their system could deal

with validation against a new schema that followed our versioning policy
anyway (which was the nature of the change to the namespace).  This
particular system also exceeds the 50% rule I was mentioning because

they are dealing with nearly all of the data in the message, so maybe it
really isn't that big of a deal.  The rubber has to meet the road
somewhere, otherwise you'll never get where you're going.

However, back to your text field example.  If you really care about

"text field" vs. the data in the text field and what it represents in
the context of your application, then yeah, you could probably describe
your UI or even other parts of your application using RDF or something

similar.  I don't think it would be that simple, though.  However, I'm
certainly no RDF expert.

It just depends on what you're after.  Perhaps I don't fully understand
what you're saying though, and you mean something different.


ast

***************************************************************************************************
The
information in this email is confidential and may be legally
privileged.  Access to this email by anyone other than the
intended addressee is unauthorized.  If you are not the
intended recipient of this message, any review, disclosure, copying,
distribution, retention, or any action taken or omitted to be taken in
reliance on it is prohibited and may be unlawful.  If you are
not the intended recipient, please reply to or forward a copy of this
message to the sender and delete the message, any attachments, and any
copies thereof from your system.
***************************************************************************************************