Key as resource in URI?
Hello, and congratulations on the CTP - intriguing stuff.
Could someone on the team give some thoughts on the decision around making the entity key encoded into the URI part as a qualifier [ ], i.e:
http://myserver/data.svc/Customers[ALFKI]/Orders
...rather than:
http://myserver/data.svc/Customers/ALFKI/Orders It would seem natural to see that ALFKI customer entity as a resource of it's own? I see how this fits into the sets qualifiers i.e. eq, gt etc. but not for something as useful as an id/name. PS First post! ;-) David
Yeah I've been wondering the same thing myself.
Actually I done a bit more thinking about this... it is probably because it is consistent with the rest of the filtering semantics... and consistency is a good thing.
More here
Perhaps, but putting a consistent XQuery (~XPath-like) syntax into the URI for *every* 'set-of' entity makes it seem a bit less 'web-like' in nature? Sometimes /customer[4E24]/orders makes a good entity to pivot from, but with a nicer/more natural URI name than the key?
I imagine because this sits about relational data then the Axes==TablesJoins and Nodes==Rows seems the most natural way coming from that direction, especially with those operators (customer[id gt 100]) maping so well to SQL expressions. Not sure yet, still playing.
I am happy enough either way, but was curious to see what options they weighed up in terms of this decision.
This is a good question. I saw that Alex asked the same in his detailed analysis (which I still owe a detailed answer for ...).
The original prototype used "/" for the key as well, just like you say (/Customers/ALFKI). The reason for moving to brackets is what Alex speculated about: all the filters are expressed in brackets; primary key filters are just a special form of filter where the parser sees a single term, it assumes it must be a constant and it matches it with the key (using the key type to type the expression).
It seemed better to have only 1 way of expressing "which subset you want" than to have two ways, one for generic filters and one for key-based filters.
Regarding the XQuery/XPath comment: I've been trying to stay away from XPath; the fact that we use URIs make things very similar to XPath, but semantics are not the same. There are on sibbling/children/parent axis, no ordinal-based access, etc.
May opinion is that we either implement XPath completely and to the letter, or we don't at all. Since XPath (XML) semantics are very hard to map to databases (which IMO will be is the most common store for Astoria services), particularly operations that assume order, we chose not to go the XPath route at all.
Pablo Castro
Technical Lead
Microsoft Corporation
Pablo,
A few questions:
1. Am I correct in assuming that you don't use the term "URI" because the Astoria URLs aren't derefencable? By this I mean: I cannot generate a polymorhphic resultset (as per one of the earlier EDM and ADO.vNext demos) that contain Entities that are dereferencable (i.e. I click on one of these Entities and I get all data about said Entity)
2. When you refere to $format=rdf, is this RDF/XML (only)? I ask because RDF serialization extends beyond RDF/XML
3. When you produce RDF (which I assume is RDF/XML) will it validate successfully against the many public RDF/XML validators? I ask because I tried this two days ago without success
To get a sense of where I am headed with these questions please look at:
http://esw.w3.org/topic/LinkedData
Astoria is a great move in the right direction (i.e. exposing access to a Concrete Conceptual Model via REST), but I would certainly like to see it move even closer to the standardization and unification effort that the burgeoning Semantic Web (RDF Data Model, SPARQL Query Language) accords.
Let's keep talking :-)
Kingsley Idehen
OpenLink Software
http://www.openlinksw.com/blog/~kidehen
Hi,
1. Actually, Astoria URIs are always "dereferensable" (or whatever the word is for "you can resolve them"). I try to use the term URI because RFC 2396 calls out URLs to be the primary access point for a resource; in Astoria there is often more than one way of referring to an entity, so the more general URI term seemed appropriate. Note that every entity does have a "canonical" or "primary" URL, which comes in the entity header (in the "uri" attribute if using XML format), but I didn't want to change terms for that case specifically.
2. Yes, currently we only do RDF+XML. In fact, if you use the "Accept" HTTP header you have to use the application\rdf+xml MIME type. I wanted to keep the $format options short, hence the "rdf" name. Maybe I pushed it there and I should have been more specific. I'm not sure we'll support other RDF encodings in the short term, but it may make sense to leave the door open.
3. Probably not 
. We found that in some cases we kind of pushed the RDF+XML format a bit. Even the docs call out that the RDF format is far from perfect. My take on the RDF support is that it is the minimum to see if it catches interest or not. If this becomes broadely used and requested, then we will take a more serious look at it, and at that point I would expect that we pass reasonable validation.
Thanks for the pointers to the LinkedData stuff, I'll do some reading and then comment on it.
Pablo Castro
Technical Lead
Microsoft Corporation
http://blogs.msdn.com/pablo
That is true.
PS I'll let the resources used on the web know they have a disambiguation problem - please expect it all to shutdown for maintenance soon, hopefully on a weekend when it's not so busy.
;-)
Not to worry -- the WS-I will likely spin up a WS-Resources Profile working group. I know just the guy to chair it.
Hi Pablo,
I have just written a blog post titled: Enterprise 0.0, Linked Data, and the Semantic Data Web, that clarifies and demonstrates what I mean by dereferencable URIs, Linked Data, RDF Data Model, RDF Serialization Formats (RDF/XML, N3, Turtle etc..).
At the current time, Astoria is emitting data from Northwind "On to the Web", which is fine, but dereferencable URIs take the concept a little further (as I demonstrate) by putting Nortwhind Data "Into the Web". In a nutshell, the data is being injected into the Semantic Data Web so that URIs (aka Object IDs) provide pointers to Entity-Set data across machine, operating system, and host DBMS engine boundaries.
The Concrete Conceptual Model approach of ADO.NET is great! But it will not take much to up the ante a notch so that Entity-Sets are plaform or framework locked. This is what the Semantic Data Web vision has always been about etc..
Some Quick Links that also demonstrate the core concepts via Dynamic Linked Data Pages:
- Customer, Employee, Product, etc. Entities Definitions (Classes) - Raw form
- Customer, Employee, Product etc Entity Definitions (Classes) - via RDF Browser
- Customer Entity-Set item (ALFKI) - standard browser interaction with linked data injected in (*follow the Explore options in the Data Link Lookup*)
- Customer Entity-Set item (ALFKI) - via Semantic Data Web Browser
- Northwind Data Space Exploration using derferencable URIs
- Northwind Ontology Exploration using dereferencable URIs
Pablo,
Quick correction to a paragraph in my pior post that confuses matters :-)
<<
The Concrete Conceptual Model approach of ADO.NET is great! But it will not take much to up the ante a notch so that Entity-Sets are plaform or framework locked. This is what the Semantic Data Web vision has always been about etc..
>>
Should have read:
The Concrete Conceptual Model approach of ADO.NET is great! But it will not take much to up the ante a notch, so that Entity-Sets *aren't* plaform or framework locked. This is what the Semantic Data Web vision has always been about etc..Let's dereference Object / Entity IDs across operating system, framework, database, and programming language boundaries :-)
