Bill
Whew, you packed a lot of thinking into
this message. Since I was in the middle of editing the V3 XDI RDF proposal (http://www.oasis-open.org/committees/download.php/22472/xdi-rdf-model-v3.pdf),
I went ahead and incorporated your suggested switch from $data to $type, as it
does seem to read more clearly.
However in looking over your points about
the XDI RDF approach to typing literal data – and I completely agree that
the contents of XDI <data> elements are literals from an RDF standpoint –
I found several reasons to propose continuing to use $is$a. Let me make the
case and see what you think.
First, I found that I was wrong in
suggesting that $data (now $type) was a core XDI RDF verb, because in the
examples I was never actually using it as a verb, only as an object. You cited one
such example, i.e., to say that the XDI RDF subject +sometype+foo is a string, the
XDI RDF statement would be:
+sometype+foo/$is$a/$type+string
One advantage of this approach, IMHO, is
that it keeps one core XDI RDF verb for all forms of type inheritance: $is$a. The
way that you can tell whether you are defining a simple datatype or a complex
datatype is from the object of the $is$a verb. All XDI RDF simple datatypes
would inherit from the $type object. This would gives us one consolidated
logical datatyping system for all of XDI.
Second, I love your suggestion about there
already being two comprehensive methods for typing literal data: xsi:type and
mime type. I was thinking the same thing. Having one $type root for the XDI RDF
datatyping system means we can accommodate both of these in the XDI $
Dictionary entry for $type just by creating subbranches for each: $type+xsi and
$type+mime. Then for each of these namespaces we just need to create algorithms
for expressing the type identifiers they have already defined as subtypes of
$type+xsi and $type+mime.
For $type+xsi, this is easy because the
XSI type names are just text strings that function as fragment identifiers in
the spec (http://www.w3.org/TR/xmlschema-2/#built-in-datatypes).
I’d vote to use the + space for simplicity and because these strings are
all typically generic nouns like string and integer. So we’d get:
$type+xsi+string
$type+xsi+integer
$type+xsi+short
…etc. In fact algorithm would
literally be “$type+xsi+[fragment-identifier-defined-in-xsi-spec-without-#-sign]”.
For $type+mime, you’re correct that
MIME type identifier syntax includes forward slashes and + signs (http://www.iana.org/assignments/media-types/).
So we have two options. #1 is to simply make them cross-references. For
example, for the XRI Resolution mime types “application/xrds+xml”
and “application/xrd+xml”, we would get:
$type+mime(application/xrds+xml)
$type+mime(application/xrd+xml)
(Note no star before the parentheses: this
is the current proposal for compact syntax – see http://wiki.oasis-open.org/xri/XriCd02/CompactSyntax).
This is very clean as it doesn’t
muck with any MIME type identifier syntax, but it does require XRI cross-reference
syntax.
Option #2 is to define an algorithm such
as you suggest for transforming MIME type identifier syntax into valid XRI syntax
that doesn’t require a cross-reference. You suggested dot in place of the
forward slash; my preference would be star. So that would give us:
$type+mime+application*xrds+xml
$type+mime+application*xrd+xml
Either option is pretty clean, and lets
use completely leverage the XSI and MIME type definitions. In addition, the
entire XDI RDF “type dictionary” is the set of XRIs in the XDI $
Dictionary rooted on $type. These can now be used as the object of a $is$a
property to declare the datatype of any XDI RDF subject.
What do you think?
=Drummond
From: Barnhill,
William [mailto:barnhill_william@bah.com]
Sent: Thursday, February 15, 2007
7:28 AM
To: Drummond Reed;
laurie.rae@cordance.net
Cc: xdi@lists.oasis-open.org;
xri@lists.oasis-open.org
Subject: RE: [xdi] Bill's
suggestions
I've been
doing some more thinking about the $data as datatype specifier concept,
particularly in light of some comments by Dan Connolly and others with the gist
that the RDF WG maybe should have used xsi:type instead of rdf:datatype (http://www.mnot.net/blog/2005/04/01/rdf_complexity).
It seems to me there are already two comprehensive methods for typing literal
data, and the contents of <data> are essentially literals (Even XDI in
there is still treated as an XML literal I think). Those two methods are
xsi:type and mime type. It seems to me also that xsi:type and mime type are
actually types of Strings themselves.
Based on that, I propose changing to the following:
+sometype+foo/$type.xsi/string
and @example/+sometype+foo//
Instead of
+sometype+foo/$is$a/$data+string
and @example/+sometype+foo//
Both state that the datatype of +sometype+foo is a string.
In addition, if I want to say that +sometype+foo is HTML we have a problem. We
have limited ourselves to 3 segments, which I have no problem with, and an XREF
has to have a root so we can't do (please correct me if I'm wrong on this):
+sometype+foo/$type.mime/(text/html)
If we use convention again and say that we are adopting the mime type
identifiers, except that our mime type major/minor delimiter is . instead of /
then we can write:
+sometype+foo/$type.mime/text.html
But what about the case where there are multiple alternate types? An example:
_:x rdf:type rdf:alt .
_:x _:1 "hello, world"^^xsd:string .
_:x _:2 "<p>hello,
world</p>"^^rdf:XMLLiteral .
(above cribbed from Jimmy Cerra's comment at the page linked above, assume base
of http://example.com)
This would be stated by the following XRIs ('data:' usage spur of the moment,
and may need rethink):
@example*x/$type.mime/text.plain
@example*x/$type.mime/text.xml
@example*x/$type.mime/text.plain//data:text/plain,hello, world
@example*x/$type.mime/text.xml//data:text/xml,<p>hello, world</p>
Looking at this if we had any kind of inference mechanism we could streamline
down to:
@example*x/$type.mime/text.plain//data:text/plain,hello, world
@example*x/$type.mime/text.xml//data:text/xml,<p>hello, world</p>
and have the valid existence of the other two XRIs inferred.
I don't like the combo of text.plain and text/plain in there, but not sure what
to do about it right now.
Ok so we can state multiple data types, but can we retrieve them by type? Sure:
@example*x/($type.mime/text.plain)//
@example*x/($type.mime/text.xml)//
<uncertainty>
If we are still supporting both the s/p/o and the auth/type/inst (a/t/i)
models, then we could even say that an XRI like
+sometype+foo/+name/+last
is by definition shorthand for
+sometype*foo/($type.xdi/+name)/+last
</uncertainty>
Which means that the XDI dictionary typing system possibly goes from the only
way to do typing to just the recommended way to type non-literal XDI resources.
The above seems cleaner to me than the N3 RDF version, and way cleaner than the
XML RDF version. Note that I have changed the meaning from the RDF version
somewhat since it seems the multiple XRIs express an rdf:bag (agent may choose
one or more of), rather than rdf:alt (agent may choose one of). Not sure how to
resolve that yet.
Bill
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thu 2/15/2007 2:01 AM
To: laurie.rae@cordance.net
Cc: Barnhill, William; xdi@lists.oasis-open.org; xri@lists.oasis-open.org
Subject: RE: [xdi] Bill's suggestions
Laurie, thanks for the reminder. To extract Bill's question, it was:
> But..is $data meant to represent actual data, or the datatype? Put
> another way, what is the relationship of
> @example+foo$data
> to
> @example+foo//
First I need to clarify that that $data is used to define datatypes as an
XDI RDF object XRI value, not as an XDI RDF subject, so I think the
appropriate question is, what is the relationship of:
+sometype+foo/$is$a/$data+string
to
@example/+sometype+foo//
What the first XDI RDF statement says is that the datatype of +sometype+foo
is a string. From that you know that any XDI RDF statement that uses
+sometype+foo as a predicate and has a literal as an object will have a
string as datatype of the literal.
More in the next version of the proposal coming shortly (either tonight or
tomorrow morning).
=Drummond
-----Original Message-----
From: laurie.rae@cordance.net [mailto:laurie.rae@cordance.net]
Sent: Tuesday, February 13, 2007 9:11 PM
To: Drummond Reed
Cc: 'Barnhill, William'; xdi@lists.oasis-open.org; xri@lists.oasis-open.org
Subject: Re: [xdi] Bill's suggestions
Drummond,
I apologize if you've already addressed this in the newest version of the
RDFX documentation, but I just wanted to follow up wrt Bill's question
about $data, given that I asked you a similar question last week. That is,
is $data meant to represent data or the data type?
And, if it is meant to represent data, how is the data type represented?
Cheers,
Laurie
> Bill,
>
> Thanks for the very helpful analysis of the RDF predicate mapping of the 5
> RDFX verbs. Paul Trevithick sent me a note with a similar analysis and I
> believe identical conclusions (we need time to study them closely).
>
> I also think that "as" is a brilliant suggestion as the English
equivalent
> of the $data predicate. I kept wondering about that one and you nailed it
> on
> the head.
>
> See my next message about the recurring question of naming of the five
> predicates.
>
> =Drummond
>
> -----Original Message-----
> From: Barnhill, William [mailto:barnhill_william@bah.com]
> Sent: Thursday, February 08, 2007 2:11 PM
> To: xdi@lists.oasis-open.org; xri@lists.oasis-open.org
> Subject: [xri] RE: [xdi] Re: [xri] Agenda: Joint XRI & XDI TC Telecon
4pm
> PT
> Thursday 2007-02-08
>
>
> I won't be able to attend the telecon, but wanted to post some thoughts
> on the RDFX doc:
>
> It would make seeing the RDF fidelity easier if the five root RDFX
> predicates table contains a column that maps to the equivalent RDF
> predicate, specifically:
>
> Predicate
English Relationship
RDF style Predicate
> $ref
"is"
equivalence
> owl:equivalentClass
> $ref$object
"is a" inheritance
rdf:type (if
> subj is an object, owl:class otherwise)
> $link
"has"
aggregation
> exns:hasXXX, where XXX is the property name specified within the link
> XRI
> $link$object "has a" composition
exns:xxx, where xxx is
> the property type specified within the link XRI
> $data
""
datatype
> rdf:parseType
>
> I'd also suggest an English phrase for data: "as", ex: "as
String"
> But..is $data meant to represent actual data, or the datatype? Put
> another way, what is the relationship of
> @example+foo$data
> to
> @example+foo//
>
>
> Exns is the prefix for a domain-specific namespace.
>
> On the 3 col graph, I like it, though I'd like to see it bigger to
> labelling is clearer.
>
> On tightening the XRI syntax within the schema there's a fairly easy way
> that makes it clear, and doesn't impose a further burden on
> implementers, but does allow them to do automated checking if they want:
> use schematron extensions within the schema.
>
> Bill
>
>