RE: [xdi] Bill's suggestions

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 "hello, world"^^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,hello, world

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,hello, world
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
>
>

xdi message