where are we on this chart?

[George Lilly]

Conor:

http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments

I have been mulling this over in anticipation of talking with you next week. 

You currently extract json from "exiting fileman triples" or near enough. And you use the json you extract in semantic applications (or near enough)..

I would like to support json in and json out of the fileman triplestore. (in addition to RDF in and RDF out.. i currently only have "some kinds of RDF in")

I'm trying to figure out how to do it in some way that either 1. leverages existing invention and code (yours?) or 2. adopts some standard or likely emerging standard on both sides (rdf representation in the triple store and json representation on the client)

Perhaps we fall in #6B or #7A.. 

I don't really like the solution of forcing the json to resemble SPARQL query results as in this:

http://www.w3.org/wiki/TriplesInJSON

... it seems unnatural for the javascript programmer.. i mean why do they care about s,p, and o anyway. 

.. but that choice is also open to us.

your insights and opinions would be very helpful.

thanks

gpl

[Tom Munnecke]

for what it's worth, I hear tell of a "VAHIM" (sp?) model bouncing around somewhere inside the VA... anyone know anything about it?

I talked to a VA security guru yesterday, who is developing an RDF-based security model...

and here is an ontology-focused approach to Genomics on Osehra: http://osehra.org/blog/genotypes-exomes-whole-genomes-and-raw-sequence-reads-electronic-health-record

So, it seems like pulling all of this together into a common namespace, mapping out a universal namespace for health information, is a cool thing to do..

[Tom Munnecke]

oh, and the Chart returns a 503 error... 

[George Lilly]

here's a tinyurl to the chart. It opens fine for me.

http://tinyurl.com/7gekuzf

[George Lilly]

Here are two different approaches: the first one is nicer to read.... would it be just as easy for a javascript programmer to use?

http://code.google.com/p/oort/wiki/Gluon 

{
    "profile": {

        "prefix": {

            "dct": "http://purl.org/dc/terms/",

            "owl": "http://www.w3.org/2002/07/owl#",

            "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",

            "rdfs": "http://www.w3.org/2000/01/rdf-schema#",

            "xsd": "http://www.w3.org/2001/XMLSchema#"

        },
        "default": "dct",

        "define": {

            "a": {"term": "rdf:type", "symbol": true},

            "created": {"datatype": "xsd:dateTime"},

            "title": {"localized": true},

            "alternative": {"many": true},

            "source": {"reference": true, "many": false},

            "Resource": {"from": "rdfs"},

            "Thing": {"from": "owl"}

        }
    },
    "lang": "en",

    "linked": {

        "http://example.org/item/1": {

            "a": ["Resource", "Thing"],

            "created": "2010-01-04T01:35:14Z",

            "source": "http://example.org/source",

            "title": "Example",

            "alternative": ["ex."]

        },
        "http://example.org/source": {

            "title": "Source"

        }
    }
}

https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html 

{
  "http://example.org/about" : {
      "http://purl.org/dc/terms/title" : [ { "value" : "Anna's Homepage", 
                                             "type" : "literal", 
                                             "lang" : "en" } ] 
  }
}

On Sat, Jan 7, 2012 at 5:13 PM, George Lilly <gli...@glilly.net> wrote:

https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html 

[Conor Dowling]

George,

I hear where you're coming from and there on and off every time I query stores.

The problem of triple stores is their advantage: any old predicate can be in a triple and, in the general case, its type is only known at runtime. This makes storing easy and comprehensive - you can capture any subject-predicate-object - but it makes client programming somewhat harder. 

The approach below covers the "identified predicate" query and most clients do this to the standard JSON before processing it: take the generic form, extract the expected schema and then process the data in a straightforward way.

But what about the most general query - SELECT ?s ?p ?o WHERE {?s ?p? o} . Here you can't binding ?p to a type. It varies. Or this: SELECT ?s ?p ?o ?oLabel WHERE {?s ?p ?o . OPTIONAL {?o rdfs:label ?oLabel}} which gives a label for URI/pointer objects with one and literal objects are rendered as is. 

The problem with optimizing for the precise is it doesn't allow for the general or sort-of-general.

We have a bunch to discuss next week,

Conor

[David Whitten]

See below

On Sun, Jan 8, 2012 at 1:39 AM, Conor Dowling <conor-...@caregraf.com> wrote:

George,

I hear where you're coming from and there on and off every time I query stores.

The problem of triple stores is their advantage: any old predicate can be in a triple and, in the general case, its type is only known at runtime. This makes storing easy and comprehensive - you can capture any subject-predicate-object - but it makes client programming somewhat harder. 

The approach below covers the "identified predicate" query and most clients do this to the standard JSON before processing it: take the generic form, extract the expected schema and then process the data in a straightforward way.

But what about the most general query - SELECT ?s ?p ?o WHERE {?s ?p? o} . Here you can't binding ?p to a type. It varies. Or this: SELECT ?s ?p ?o ?oLabel WHERE {?s ?p ?o . OPTIONAL {?o rdfs:label ?oLabel}} which gives a label for URI/pointer objects with one and literal objects are rendered as is. 

The problem with optimizing for the precise is it doesn't allow for the general or sort-of-general.

The ontology community has some solutions for this. Both Cyc (http://www.cyc.com) and SUMO (http://http://www.ontologyportal.org/ ) have had the issue of "typing" for triples for years. (Actually, they have n-tuples, not just triples, but the solution for 3-tuples is a degenerate case of  the stuff they have.)  Their solution has been a series of predicates which specify meta information about the predicates of the triples.  

For example, they have a way to talk about characteristics of the arguments to a predicate.

There is a predicate named "arity" (Cyc) or "valence" (SUMO) which identifies the number of arguments to a predicate.  Of course for triples, this number is always 2.

Another predicate "argIsa" (Cyc) or "domain" (SUMO) specifies that any value for a given argument of a predicate must be an instance of a Collection (Cyc) or Class (SUMO). Usually this is a quaternary predicate, but when expressed as a group of separate predicates i.e. "arg1Isa" or "arg2Isa" or "arg3Isa" etc, it can be expressed in a triples form.

Another predicate "argGenl" (Cyc) or "domainSubclass" (SUMO) specifies that any value for a given argument of a predicate must be an specialisation of a Collection (Cyc) or or a subclass of a Class (SUMO).

There are also ways of specifying inter-argument contraints so if one argument can be characterized as functional or an instance of a particular category that the other arguments must have particular features.
 
Finally, there are ways to say how many triples can be expected to exist between a subject and object for a particular predicate, similarly to the way that fields in FileMan are either single-valued or multiple-valued.


 

We have a bunch to discuss next week,

Conor

 I definitely agree
David
713-870-3834

[conor dowling]

Dave,

you can define things like domain/range for triple stores in plain
RDFS too and when the client has a definition of predicates then a
library can take any standard JSON response and turn it into a more
"natural" equivalent:

"name": {"value": "George", "type": "literal"} ---------->
"name": "George" where the client knows that predicate "name" is a
string and not say a date or number or other kind of literal.

But in the most general case the client discovers as it goes, finding
new predicates and needs to be told - at least - that the value's
range is a Literal, typed-literal or URI. Hence the "type" field. Of
course, the powers that be could have defined predicate ranges in a
header section and avoided restating them for every assertion but ...
Also inline ranges are easier for simple "show me" clients (in
browser).

BTW in FMQL, I do serialize the JSON based on FileMan types -
http://repository.caregraf.org/fmql/file/tip/MUMPS/FMQLJSON.m . See
the "typed-literal" ref which catches date etc. Also "WORD PROCESSING"
fields are typed as "XML Literal" and not plain "Literal". I followed
SPARQL in "inlining the range" and not defining the scheme in a
header.

> > The problem with optimizing for the precise is it doesn't allow for the
> > general or sort-of-general.
>
> > The ontology community has some solutions for this. Both Cyc (
>

> http://www.cyc.com) and SUMO (http://http://www.ontologyportal.org/) have