[ckan-discuss] API For Package Name

Sun Nov 28 14:55:23 GMT 2010

* [2010-11-28 14:00:20 +0000] John Bywater <john.bywater at appropriatesoftware.net> écrit:
]
] I also found a message from Jeni Tenison, which started a long thread:
] http://www.mail-archive.com/public-lod@w3.org/msg04086.html
] 
] [...]
] 
] So, looking at all this from a distance, there appears to be two poles: 
] RDF for RDF-enabled developers and RDF-enabled generic tools, and (for 
] the sake of simplicity, let's assume) domain driven design for "normal" 
] developers who are writing "normal" applications.

Yes, the RDF/JSON is basically used to avoid needing to parse RDF. 
Apart from that it is just another serialisation, the data model stays
the same.

That's why I made http://bnb.bibliographica.org/isbn for the Wikimedia DE
folks, it's lossy but easy to understand.

] I should admit that my head nearly exploded trying to match up RDF with 
] domain driven design. Metaphorically speaking, I had to switch 
] everything off for a while and allow the heat to dissipate. I was left 
] with the impression that there's a gross impedance mis-match between 
] domain driven design and RDF. That is to say:

:)

] 1. A domain model is a model of behaviour-state. An RDF model is a model 
] of state (RDF models behaviour as state). That is, a Domain model 
] constitutes its own changes of state, whereas an RDF model expects 
] something external to constitute changes of state.

There has been some work recently that could introduce some notion of
state transitions -- it's tied to provenance:

      http://iswc2010.semanticweb.org/accepted-papers/241

so to express the state change from t0 -> t2 you write down the
SPARQL SELECT/INSERT/DELETE statements that describe the transition
(more or less). You do the writing down in RDF. So the transition
behaviour itself becomes state in the code is data sense.

I could imagine (not saying this would be a good idea) carrying around
snippets of python code for operating on the data in the data itself
to express more or less the same thing. But this is maybe a bit "out
there". 

] 2. If CKAN presents JSON with absolute URLs where there are currently 
] invariant UUIDs (in Version 2, or variable names in Version 1), which 
] existing tools would be able to undertake traversals? For example, would 
] Googlebot (or anything else in operation today) treat URLs in JSON as 
] links, and follow them?

I'm not sure but I don't think Googlebot will follow them. However for
the existing spiders there are always the html pages that contain
parallel linkages that they can crawl.

] 3. Can we make use of the HTTP 'Accept' header? We could continue to 
] support DDD with application/json and introduce support for RDF with 
] application/rdf+xml. We could discriminate with content negotiation.

Yes this is a good idea. There's already some less automatic linkage
in the HTML header and a "human click on this if you want RDF" link in
the page. Autoneg would also be trivial to implement -- "requested
some RDF? 303 -> semantic.ckan.net".

] 4. Where does DCat fit in? Could DCat be the data format used to 
] represent a package entity for clients that prefer response content type 
] of application/rdf+xml? Would DCat be able to represent a package 
] register? Or should we use other RDF elements for that? What about the 
] other objects of the model, such as groups?

DCat is just a vocabulary used in RDF. It represents some elements of
a package registry, but other vocabularies are used as well. For an
example, see http://semantic.ckan.net/package/bas-clamp.n3 and 
http://semantic.ckan.net/catalogue.n3 (note, turtle or N3 will be much
easier for you as a human to read. Pay little attention to RDF/XML
unless you are a computer). 

] 5. Can CKAN support RDF-enabled developers and RDF-enabled generic tools 
]  as a viewpoint on its domain model? The good thing is that the list of 
] use cases for the semantic web is very short, and there ought to be (in 
] the language of domain driven design) a cohesive mechanism for it. "The 
] collection of Semantic Web technologies (RDF, OWL, SKOS, SPARQL, etc.) 
] provides an environment where application can query that data, draw 
] inferences using vocabularies, etc." That is, apart from fixing the 
] content type, we can at least imagine that CKAN could support queries.
] http://www.w3.org/standards/semanticweb/data

It already does: http://semantic.ckan.net/sparql and above links...

There's always room for improvement of course, most immediately
separating out extension descriptions (e.g. so that Richard can
generate voiD separately and have it pulled into the store) and doing
something similar for the other instances, but I think CKAN already
has the proverbial 5 stars.

] PS Can we do it? Yes we CKAN! :-)

Yo Bob!

-w
-- 
William Waites
http://eris.okfn.org/ww/foaf#i
9C7E F636 52F6 1004 E40A  E565 98E3 BBF3 8320 7664