(Mr. Brickley: please see point [1] later in this note, about 4/5 of the way
down)
> I think that the editor discussed earlier provides some insight into the
> potential role of SDF. RDF is a static descriptive entity, but most
> Semantics are largely driven by dynamic content -- if things didn't
change,
> then all of this would be simple, but it would also be dull ... there
really
> wouldn't need to be a rich framework for describing semantics in the first
> place.
These essence of SDF is this:-
1. Provide a backbone namespce for SDF that uses (HTML) display tags.
2. Fill this framework with your own, Schema described content, dynamic and
logical
a. Dynamic becuase you make it up: generate on the fly
b. Logical because to work it would require logic rules
ReGex sounds very useful for this.
> Natural Language Processing, unfortunately, isn't necessarily all that
> reduceable. [...]
See my post Re: Semantic Document Framework(s) [language]
> Thus an SDF framework would require (as I see it) the following
components:
> 1) A schema for encoding abstract information about a document. This may
be
> RDF or some logical superset of RDF, encodings on an XSD schema (perhaps
as
> a namespace for use within the annotation node), or some new schema
format.
Yes, this is the most basic level of SDF: the Schema layer, then the
descriptive layer, then the logical layer. TimBL put it this way: [[[
> Basic assertions, Schema layer, Conversion Languages,
> The logical layer, Proof Validation
]]] - edited down from headings on the Semantic Road map (I think)
> 2) A rules based mechanism for mapping the contents of a document of a
given
> schema to it's corresponding SDF schema. This would probably be best
served
> as some combination of XSLT and Regular Expressions, working against an
> encoding contained within the SDF schema.
There are two systems at play here:
1. Dynamic content
2. Rules for creating and managing that content
The dynamic, and static (for there will still be static content) content,
will be managed by SDF Schemas (which is an XML/RDF Schema for an SDF
document). The rules will be encoded into namespaces. I'm not sure about the
mechanism for that yet. Oh, you could import another schmea into that
Namespace: yes, that would work.
> 3) A linking mechanism that would register a document or document space
and
> create xlink associations dynamically. This may introduce the notion of
> weighting or LODing the space to create a more holigraphic architecture.
Hmmm.....deja vu of "fractal dimensions" as well, there.
> 4) A garbage collection mechanism that would delete broken links, simplify
> the database periodically, reduce the complexity of the SDF instance, and
> perform notifications to other subscribers to the SDF framework when a
> document changed.
SDF subscribers? It seems that this framework has grown alrady from a
document format into a fully Semantic system. Should have allowed for that
in the original note. That means I'll have to re-write it now...
We're going to be using an awful lot of XSLT for all of this, aren't we?
> It should be noted that a framework is not in and of itself a standard,
> though SDF encoding may be.
Exactly!!! I've been trying to get that point across to everyone for ages
now. You can have an outline of the SDF system, to help programmers as to
what is going on, but there is *not* going to be a specification: you can
never do anything "wrong" . However, you can in SDF encoding...it should
validate! (O.K. has to, unless you just use namespaces).
> Thus there is a question as to what degree this should get pushed into the
> W3C as a standard, and how much of it is simply an application, albeit
> one of great import.
[1] I don't feel that the W3C will take this up in a million years: simply
because I haven't got a clue who to submit it to. I've CC'd it to Dan
Brickley, chair of the RDF IG, in case he's interested, but 1000:1 etc...
SDF could be published as a note or something: "A Generic Description of the
Processes in SDF".
> SDF makes a great deal of sense
> in the move toward distributed programming, since we're rapidly
approaching
> a point where we were a decade ago with the host of file retrieval
protocols
> and no real idea about what the files they point to actually contain. The
> difference is that in most cases there was NO semantic information in 1992
> beyond what little that could be gleaned by looking at the filename, while
> with XML we have the capability of creating very extensive semantic
> structures.
It makes a great deal of sense altogether: a framework for semantic
documents - combining data and documents (text is data too), and displaying
it semantically. If developed correctly, it could evolve into the the most
viable SW application (well, framework: not really an application), and I
hope it does.
Kindest Regards,
Sean B. Palmer
----------------------------------------------------
The Semantic Web: A Resource - http://xhtml.waptechinfo.com/swr/
WAP Tech Info - http://www.waptechinfo.com/
Mysterylights.com - http://www.mysterylights.com/
----------------------------------------------------
"The Internet; is that thing still around?" - Homer J. Simpson