Re: Links and graphs

hello graham.

On 2012-12-17 6:32 , Graham Klyne wrote:
> It seems to me that RDF (in its various syntaxes) is a natural way to
> provide a service description.

it may be for a specific service, and in particulat for one that's 
RDF-centric. for providing a more comprehensive starting point, 
http://www.rfc-editor.org/queue.html is under development, but of course 
ou could argue that this could/should be RDF instead. it could, of 
course, but the important aspect always is that a client needs to know 
what it needs to know to use this kind of resource, so you would have to 
define a media type that makes that clear. it's application/json-home in 
its current form and you can recast this as application/json-home+turtle 
or something else to your liking to provide a more RDF-friendly variant. 
but in the end, there has to be some definition of how this works 
somewhere, and if you would RDFify mark's work, you might just reference 
his semantics, and create some RDF vocabulary for it.

> A client application needs to understand
> about RDF in general, and about specific RDF vocabularies that are used
> to describe services.  A service provider can introduce new mechanisms
> by introducing new descriptions (using new vocabulary terms) into the
> RDF returned, without breaking existing clients.

here you're taking a turn into a RDF-only world. which is one possible 
way to go, but not the web. if you want to provide a fabric that any 
client can use, then you have to tell them what they need to know to 
make things work. it's fine to tell them "parse turtle, create an RDF 
graph, and then interpret the following triples you find in there in the 
following way", but that's something you have to tell them. how else 
could somebody could write a functioning client? you have to communicate 
the expectations for clients in a way that allows people to build those 
clients.

> I think this approach is entirely consistent with Roy Fielding's
> description of REST, in which a representation is "a sequence of bytes,
> plus representation metadata".  The metadata may include, but is not
> limited to, a media type description.

i have to admit that i never went far in exploring this direction, 
because my area of research and work is "REST as the way URIs and HTTP 
are used in today's web fabric." i assume you could really treat REST as 
what it is, an architectural style, and come up with a different design, 
firmly based on REST and assuming that whenever information is being 
exchanged, it is in the form of some RDF. you might be able to design 
such a system, and it actually would be an interesting thought 
experiment. on the other hand, you would not have interoperability 
between today's fabric, and that hypothetical other one, so it's not a 
decision to be taken lightly.

> Thus, in our RDF service description for accessing provenance, we might
> describe either or both of:
> (1) a REST service description, e.g. per
> http://www.w3.org/TR/prov-aq/#provenance-service-description, which
> introduces a resource with RDF type 'prov:ProvenanceService' (this is a
> fairly old PWD which is undergoing revision - part of my reason for this
> discussion is to figure out what should go here).  One point of ongoing
> debate is whether the RDF type should cover all of the access mechanisms
> (REST and SPARQL).

if you're planning to add general ways for how clients can find PROV 
information for a resource, i'd like to encourage you to use RFC 5988 
and register something like "provenance" (if it cannot be folded into 
something that already is well-known on the web), so that the entire web 
community can use this interlinking consistently.

> But this does not use media type to discriminate between the options.

what i am wondering how my simple web client, using an XML-based access 
to your data, would then find out. it seems you're making assumptions 
about the URIs based on their context, instead of providing URIs that 
are self-contained and could be taken entirely out of context and still 
would allow me to interact with the services. could you breifly show how 
you would, if you were building non-RDF access to your service, expose 
the PROV links?

> Depending only on the client's knowledge of how to process the media
> types seems to me to be a narrow view compared with "examining and
> choosing from among the alternative state transitions in the current set
> of representations" [Fielding].  I'm concerned that this dependency
> leads to an overloading of media types, which "specify the native
> representation (canonical form) of such data"
> [http://tools.ietf.org/html/rfc2045] to also cover data semantics.  For
> formats where the semantics is tied to a specific format, this seems not
> to be a problem, but does not sit so well with RDF which uses common
> syntax to convey arbitrary semantics.

there seems to be this lingering feeling that "RDF is different" because 
"it's semantics, and not a format". pretty much all data formats (apart 
from those using ad-hoc syntaxes) work exactly that way, so there really 
is not need to deviate from what has been working in the past 20 years. 
application/atom+xml is atom semantics using xml syntax, and if somebody 
felt the urgent need to provide that in EXI, they would need to register 
application/atom+exi and then people could start using atom with a 
different xml syntax. in the end, clients need to know what they have to 
parse when they start GETting something, so you must say which 
syntax(es) are available. personally, i don't think providing multiple 
syntaxes is a very good idea, but that's just my personal opinion. but 
as a matter of fact, pretty much all structured data services today use 
the exact same setup of "parse the data based on some general-purpose 
underlying syntax", and then "start processing the data based on some 
assumption what kind of vocabulary is expressed within that syntax." RDF 
is doing exactly the same as XML or JSON, just with a different syntax 
and metamodel.

> One thing we lose by not using a media type to distinguish between the
> access options is the ability to use content negotiation for selection.
> I think this is somewhat offset by a server easily being able to supply
> multiple RDF descriptions in a single response, so the process can
> proceed without any additional round-trips.  (This doesn't preclude the
> use of media types and content negotiation for non-RDF service
> descriptions, so I think the essential flexibility and evolvability of
> the REST style is not compromised.  In future, maybe we have a way to
> negotiate on RDF types?)

i don't think that RDF will ever become part of HTTP-level operations. 
we can negotiate on media types because that's what the uniform 
interface is using. and you can easily negotiate on RDF types as well, 
but you must make them part of the uniform interface. if you started 
introducing RDF-specific mechanisms in the uniform interface, it 
wouldn't be uniform anymore, because these things would be only usable 
for RDF clients, and then we'd have the split i was mentioning above. 
i'd really like to avoid doing that, because i think that both the 
non-RDF web and RDF would benefit tremendously from talking more to each 
other.

> In summary, I think there can be alternatives to using media types for
> guiding the "how?" of interactions, without compromising the essential
> evolvability properties of REST.  But maybe you can point out where the
> problems lie in the approaches I sketch here?

i've given it a try. would you mind re-reading my last paragraph in the 
last response and specifically walking me through the über-PROV example 
(and let's assume that über-PROV is not going to be RDF-based, but is 
just so clearly superior that people want to start using it) and how you 
would see that playing out in your architecture? just don't make the 
assumption that clearly, going forward, everything useful that will ever 
happen on the web will be using RDF. this is just not how it's going to be.

thanks,

dret.

Received on Monday, 17 December 2012 17:18:10 UTC