Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-06-17

[Drummond Reed <drummond.reed@xdi.org>]

Following are the minutes of the unofficial telecon of the XDI TC at: 

Date:  Thursday, 17 June 2010 USA
Time:  1:00PM - 2:00PM  Pacific Time (21:00-22:00 UTC)

ATTENDING

Bill Barnhill
Markus Sabadello
Giovanni Bartolomeo
Drummond Reed


1) XDI JSON SCHEMA 

Bill sent a proposed JSON schema to the list:

  http://lists.oasis-open.org/archives/xdi/201006/msg00022.html

Bill reported:
 * The most major change in the version to be published this weekend is the addition of plural types (booleans vs boolean)
 * An example document is forthcoming this weekend as well, an X3J JSON representation of the PDX X3 Simple document Drummond posted. This is mostly complete.

Bill points out two benefits to the schema he is developing:
 * You get direct type checking in JSON (e.g., booleans)
 * You can create new JSON schemas for a specific type of XDI documents (such as PDX documents)

Markus had not been building data types directly into his X3J serialization format because they would be described in XDI, either by extending the predicate describing them or by putting the definition into the accompanying XDI dictionary.

Markus is concerned about adding data types directly into the graph since then it would be something that all serialization formats need to support.

For example "3"^^xsd:int is a way RDF specifies an int literal.

Options for type informations:
1) Where you need it in the graph, specify it with XDI using predicates with an type suffix extension
2) Have it solely in the XDI dictionary
3) Having serialization support specifying type natively in serialization format (that might not rule out that when in an XDI information model it gets converted to predicate typing, not sure implications)

Pro: Nice from developer perspective for typing, 

Con: Complexity of doing that in each serialization format

2) COMPATABILITY WITH COOL URIS

Giovanni sent a writeup about the use of standard RDF URIs in  XDI:

  http://lists.oasis-open.org/archives/xdi/201006/msg00023.html

The discussion was about how to encode  standard RDF URIs as XDI addresses.

Giovanni began be explaining that with cool URIs there is a distinction btw URIs which resolve in resources with a representation, i.e. a document (so called "information resources), and resources which represents concepts, people, things, and so on. The latter use # to be distinct from the former

So for example, consider how to assign a "cool" URI to giovanni, it could be:

    http://example.org/about#giovanni

whereas 

    http://example.org/about

would resolve into an information resource (e.g. an html page or an RDF document) which describes giovanni (and maybe other individuals).

In FOAF we had this cool URI:

    http://xmlns.com/foaf/spec/#term_familyName

In XDI we could have statements like these:

+familyName/$is/(http://xmlns.com/foaf/spec/#term_familyName)
(http://xmlns.com/foaf/spec/#term_familyName)/$is/+familyName

Which state that our +familyName is just a synonym for the cool URI http://xmlns.com/foaf/spec/#term_familyName

Drummond agrees with this with one outstanding issue: 

+familyName (or +family+name) is an absolute XRI
(http://xmlns.com/foaf/spec/#term_familyName) is a relative XRI

So perhaps 
+familyName/$is/+(http://xmlns.com/foaf/spec/#term_familyName)

Also... 
If you want to say XRI 

@example/+founder

is an alias to http://xmlns.com/dc#creator then would this be allowed:

+(@example/+founder)/$is/+(http://xmlns.com/dc#creator)

Does this then become a generic alias mechanism, and if not how would it relate to XRI aliases?

Bill agrees this is a bad example above, dc:creator is broad.
Given that though, also with the mapping above how would 

@example/+founder+name

be mapped?

+founder/$is/+(http://xmlns.com/dc#creator) maybe?

Giovanni asked, why do you want to specify a "domain" for +founder (i.e. @example)?

Here is an example with a narrow scope:

@golf+club+member+drummond/$is/(http:golfclub.com/people#drummond)

Giovanni said this is a much better example of what he was thinking of.
And does it without the multiple segments, so IS there any use case where we would need multiple segment XRI mapped to a URI?

Drummond said he can't think of one now, but his gut says there would be one.

In Giovanni’s model, he always uses concatenation for subject, except when you have a reification:

(=drummond/+friend/=markus) <-- the fact asserting that drummond has a friend markus, i.e.
(=drummond/+friend/=markus)/$is$a/+trueFact

(Bill asks, as a side note, would +truth+true be better than +trueFact? Giovanni answers: yes, I was just giving an example, I have no strong opinion on +trueFact :-)

Drummond raises the question: is it always the same GCS character that gets prepended to the URI cross-reference, or is it dependent on the type of resource? For example:

+familyName/$is/+(http://xmlns.com/foaf/spec/#term_familyName)
=drummond/$is/=(http://equalsdrummond.name#drummond)

The first uses + because the concept is generic; the second uses = because the resource is an individual authority.

Drummond wants to ask one quick question:

CURRENTLY:
$d$first
$d$last

$
  $d$first
      "2010-06-16T01:02:03"
      
SHOULD THIS BE?
$first$d
$last$d

[side note from Giovanni: to me it could be:
$$d
   $first
       "2010-06-16T01:02:03"
       
and because I'd like to avoid confusion with $$ used for variables
$this$d <!-- the set of dates of this document -->
   $first  <!-- first element of that set -->
       "2010-06-16T01:02:03"
       
where $this has exactly the semantics you are assigning to $ in PDX example] 

Drummond wants to point out that as of the last update to the wiki spec, the proposal for variables was changed to $($). 
Giovanni is not so happy with this proposal :-(
Neither is Bill.
    
Example: $($foo)

Drummond explained the two reasons for this proposal were:
1) To eliminate the problem Giovanni pointed above - so you don't end out with $$ appearing in extensions of $ (e.g., extending $ by $d would produce $$d, which now will appear to be a variable).
2) $$ is two XRI subsegments. That causes problems. $($) is a single XRI subsegment, which means you don't need to parse across subsegments to understand that you have a variable.

Bill said the original idea from way back when was to have variable be $(x) where X is the variable Id. This also allows a variable name to be an XRI.

Drummond replies that the challenge is that $(someuri) is a valid XRI that may not be a variable. Example: $(http://example.com/) is a way of refering to a web resource (information resource) as an XRI. 

Bill asked, isn't the new way of doing that +(http://example.com/)?

Drummond gives the example of +(http://wikipedia.org/turtle/)/$is/+turtle

Bill asked: so..let's say republicans are talking turtles and democrats are as well and their POVs are opposed:
@(http://democrats.org/turtle)/$is/+turtle
@(http://republicans.org/turtle)/$is/+turtle

Drummond believes the semantics Bill is trying to express would be:

@(http://democrats.org)/$say/(+(http://democrats.org/turtle)/$is/+turtle)
@(http://republicans.org)/$say/(+(http://republicans.org/turtle)/$is/+turtle)


Giovanni: sorry but very broad terms e.g. +familyName, +email, etc. should be always assigned to well consolidated URIs!

@democrats+turtle
@republicans+turtle

Drummond points out that @democrats+turtle could also be expressed using URIs as
@(http://democrats.org/)+(http://wikipedia.org/turtle)

Giovanni: yes!

Giovanni asked: Given the above and + working well above, why do we need to save the form $(http://wikipedia.org/turtle)? And what is the semantic difference between that and +(http://wikipedia.org/turtle)?

[And also: is there any cool URI synonym of $d <a date>?]

Drummond responds: for the case where the XDI author does not know -- or does not want to assert -- the global context of the URI. For example, in Bill's question above, $(http://wikipedia.org/turtle) is not asserting any particular global context, just the SELF context.

Drummond notes that this means there's one exception to his proposed axiom that $is statements must have the same global context for both subject and object - the except is $ statements. So it would be legal to say:

$(http://wikipedia.org/turtle)/$is/+(http://wikipedia.org/turtle) is valid, but
@(http://wikipedia.org/turtle)/$is/+(http://wikipedia.org/turtle) is NOT valid, because the same resource cannot be both an @ and a +

Giovanni does not agree and fear this could create some confusion. For example we have $d which is a date, suppose there exist a "cool" URI for this concept:

$(someuri)/$is/$d

so proposal is to leave +, =, @, and $ as in their XDI semantics

Drummond understands Giovanni's concern, but the problem is going to be with the semantics of $ meaning self-context.

Bill believes Giovanni has a good point, but he needs to think about it more offline to wrap my head around it 

Bill disagrees with $first$d as I'm using $first as a function, an operator on the set $d that restricts to a particular member of that set. $first$d would then be a restriction on the set of things that are firsts, restrict to the ones that are dates.

Giovanni, proposes using $this instead of $ to mean the current context.

Drummond points out that while this is easier to read in English, it doesn't change the fact that the semantics of $ are already defined to have that meaning. 

$this <-- the current context

Bill suggests that we have a dedicated telecon on $ semantics.

Giovanni: to me $ is just a gcs, like +, =, @ etc. that's why I would like to have something more explicit for "the current context", i.e. $this

 
3) NEXT CALL

The next call is next week at the regular time.