[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ANN]: SIX
- From: Peter Jones <peterj@wrox.com>
- To: "'Clark C. Evans'" <cce@clarkevans.com>
- Date: Tue, 09 Jan 2001 10:38:52 +0000
Hi Clark,
Assuming I were to take this seriously... ;)
That's difficult to say, because I haven't done any sort of formal analysis.
However, I would suggest that they are roughly equivalent at the basic
instance level (although I've gone to enormous lengths - a couple of minutes
thought, at least ;) - to try and ensure that a clear delineation between
assertions and rules remains in SIX [SIX contains only assertions, and only
points at rule-sets], whereas I think there is some logic overflow in RDF).
However, I feel that it is far too easy to burden RDF with domain specific
syntax (which is imho a foul idea) and for which you need a weighty schema
that mixes all sorts of approaches.
You can do all sorts of things with SIX but the syntax remains the same.
The schema level is totally different. I provide only for assertion
templates (or something), and the current mechanism of SIX allows you to
assert properties of slots as #PCDATA in a <wcvar> element if you want to do
that sort of thing. If you want datatype validation for a type of SIX
document write a separate XML Schema.
cheers,
Peter
-----Original Message-----
From: Clark C. Evans [mailto:cce@clarkevans.com]
Sent: 09 January 2001 01:32
To: Peter Jones
Subject: Re: [ANN]: SIX
How does this relate to RDF?
;) Clark
On Mon, 8 Jan 2001, Peter Jones wrote:
> Date: Mon, 08 Jan 2001 14:05:45 +0000
> From: Peter Jones <peterj@wrox.com>
> To: "'xml-dev@lists.xml.org'" <xml-dev@lists.xml.org>
> Subject: [ANN]: SIX
>
> In the spirit of making the times more interesting, I knocked this up on
> Sunday night. Maybe it's a joke and maybe it isn't --I'm not the greatest
of
> spec writers and I haven't been in computing long enough to claim to be
any
> kind of expert -- it just seemed like a good idea at the time, and maybe
> someone will find some useful idea in there somewhere. If anyone wants to
> take it seriously, drop me a line.
>
> -pj
>
> Specification for SIX ("Stuff in XML") -- Draft for version 1.0
> Copyright Peter P. Jones 2001, peterj@wrox.com
> This version: 2001-01-07
>
> AIMS:
> To create a really useful interchange format for Stuff - metadata
> information, or whatever. So here is SIX (pronounced 'six'), an attempt to
> do all those useful things - and any others you can think of - in a neat
> way. I'm not going to specify much in the way of processing if at all. Do
> what you like with it.
>
> STRUCTURES ( - brackets are for clarity) :
>
> statement ::= (subject (object*| wcvar*)) -- statement is a subject and
> zero or more objects or wildcard placeholders
> subject ::= (predicate(object+| wcvar+)) -- subject is a predicate
> attached to at least one object or wildcard placeholders
>
> A predicate is a name string.
>
> A statement can be qualified by the optional 'reciprocal' qualifier to
state
> whether the predicate is bi-directional or not.
> reciprocating statement ::= reciprocal(subject (object* |wcvar*))
>
> A statement can be qualified by an optional 'namespace' qualifier to
> indicate whether the statement is only valid within a particular
namespace.
>
> namespaced statement ::=
> namespace(namespaceName, (subject (object*|wcvar*)) )
> OR
> namespace(namespaceName, reciprocal(subject (object*|wcvar*)) )
>
> A namespaceName can be any string.
>
> Although 'namespace' is treated as a keyword here, assertion of
containment
> of one namespace by another can be asserted with a
> standard statement - 'contains' is not a keyword here, just a predicate
> chosen by the statement author:
>
> (contains(namespaceName) (namespaceName) )
>
> So this statement can also be namespaced
>
> namespace(namespaceName, (contains(namespaceName) (namespaceName) )
>
> And so on for predicates other than 'contains'.
>
> Every statement has an ID that is unique within the document.That is, the
ID
> on the left-hand side of this statement MUST be unique within the
document.
> ID <- statement
> Any ID string within a statement's objects that matches a statement's ID
> could be considered to be a reference to an ID on the LHS. A statement
> should not refer to its own ID - but you could do that if you were that
way
> inclined.
>
> An object can be an ID string, or a string in a namespace. An object can
be
> a URI for example. It is up to the processing system whether the URI is
> understood to be an address of a resource or not.
>
> In interchange XML syntax (Example):
>
> <?xml version="1.0" ?>
> <six type="TopicSet" about="whateverThemeYouWant">
> <statement ID="asdf234ff25"
namespace="//ME//MYSELF//andTheBigBrownBear/--"
> >
> <subject>
> <predicate predicatename="is-in-love-with" reciprocal="yes">
> <object objstring="YOUR7686868" ></object>
> <object ...></object>
> ...
> <object ...></object>
> </predicate>
> </subject>
> <object ...></object>
> <object ...></object>
> ...
> <object ...></object>
> </statement>
> <statement>
> ...
> </statement>
> <ruledoc rulesref="http://..." >Some text describing the rule-set or
> something like that</ruledoc>
> ...
> <ruledoc rulesref="http://..." ></ruledoc>
> </six>
>
> The <six> root element has an attribute 'about'. This can be used by the
> document author to suggest that the statement set is concerned with some
> thing rather than others. The recipient of a SIX document is under no
> obligation to pay any attention to this suggestion, and can treat the data
> in ways that do not respect this suggestion if they wish to do so.
>
> The <six> root element also has an attribute 'type'. This can be used by
the
> document author to suggest that the document is a particular type of SIX
> document as opposed to others. The recipient of a SIX document is under no
> obligation to pay any attention to this suggestion, and can treat the data
> in ways that do not respect this suggestion if they wish to do so.
>
> <ruledoc> elements are an entirely optional means of indicating an
> association between some set of rules specified elsewhere with the
statement
> set in the document. SIX document recipients can choose to ignore this
> indication if they wish to do so. How recipients deal with the indication
if
> they don't ignore it is entirely up to them.
>
> SIX can have schemas for statements. These differ only from statement
> instances in that they can contain wildcard placeholders if desired. These
> can be partial statement schemas, containing a mixture of objects and
> wildcard placeholders, or complete schemas containing only wildcard
> placeholders (<wcvar> elements in the XML syntax).
>
> Statements have a 'grouped' attribute. This indicates whether a statement
> should be viewed as:
>
> grouped="yes" implies:
> (v1, v2, v3, v4,...) -- predicate -- (x1, x2, x3, x4,...)
>
> grouped="no" implies:
> v1 -- predicate -- x1
> v2 -- predicate -- x2
> v3 -- predicate -- x3
> v4 -- predicate -- x4
> ...
> Recipients can ignore the indication provided by the 'grouped' attribute
if
> they wish to.
>
> SIX XML DTD (Normative):
>
> <!ELEMENT six (statement*, ruledoc*) >
> <!ELEMENT statement (subject, (object|wcvar)* >
> <!ELEMENT subject (predicate) >
> <!ELEMENT predicate (object|wcvar)+ >
> <!ELEMENT object (#PCDATA) >
> <!ELEMENT wcvar (#PCDATA) >
> <!ELEMENT ruledoc (#PCDATA) >
> <!ATTLIST six
> about CDATA #IMPLIED
> type CDATA #IMPLIED
> >
> <!ATTLIST statement
> ID CDATA #REQUIRED
> grouped (yes|no) "no"
> namespace CDATA #IMPLIED
> >
> <!ATTLIST predicate
> predicatename CDATA #REQUIRED
> reciprocal (yes| no) "no"
> >
> <!ATTLIST object
> objstring CDATA #REQUIRED
> >
> <!ATTLIST object
> rulesref CDATA #REQUIRED
> >
>
> Licensing: It's Smileware. Anyone can use this in any fashion they like as
> long as they give someone a big smile before/during/after implementing SIX
> in a system.
>
> DISCLAIMER: The Author (Peter P. Jones) of this specification accepts no
> liability whatsoever for anything bad resulting from the use of SIX.
>
>
> cheers,
> Peter
>
> Peter Jones
> mailto:peterj@wrox.com
>
>
>
>
>