OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.


-----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
> spec writers and I haven't been in computing long enough to claim to be
> 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
> 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
> 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
> 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
> 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
> on the left-hand side of this statement MUST be unique within the
> 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
> inclined.
> An object can be an ID string, or a string in a namespace. An object can
> 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"
> >
>    <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
> 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
> 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
> 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
> 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