Interaction semantics in RDF (Re: Section 4: LDPR/non-LDPR formal definitions)

Hi Erik,

On Wed, Mar 27, 2013 at 4:59 AM, Erik Wilde <dret@berkeley.edu> wrote:

> actually, after re-reading a couple of threads, i think it's actually
> better to think of text/sgml and text/html as the two similarities to
> the discussion we're having. would the web have happened if there was
> just text/sgml, a highly structured and very successful document format
> for content management? if you had the chance today, would you not
> create text/html and instead rely on text/sgml only?


Very nice analogy indeed! I think it is very relevant to the discussion
here.

My two cents on this question:
the difference between SGML and RDF is that (AFAIK), an SGML document
complies with a single DTD, defining the whole semantics of the document.
An RDF graph, on the other hand, can contain a mix of different
vocabularies, each of them bringing its share of additional semantics. This
is an important feature to RDF people.

The argument agains the RDF stance that I found the most compelling is that
we must/should make the interaction semantics visible in the metadata
(headers) rather than just in the data.

In fact, I think this problem exists for RDF even without LDP, provided
that we extend the notion of "interaction semantics". In the current
(read-only) linked data cloud, an agent "interacts" with RDF data by doing
something useful with it (possibly following *some* of the links), based on
the terms it "understand" in the data (which might be a subset of the terms
actually used in the data).

So in order to maximize the usability of their data, data publisher often
provide redundant information, using multiple overlapping vocabularies.
This is still better than XML (forcing you to chose *one* vocabulary) but
not ideal. It would be good if the agent could negociate with the server
and only get the data it can understand.

Note that media-types are not a solution here, because RDF uses multiple
vocabularies, and so there are multiple possible combination. For example,
I can use DC or BIBTEX for documents, and FOAF or VCARD for authors.

So I think the idea of profile fits the bill, better than media-types, as a
resource can have several profiles (as I understand it, at least).

what would be the
> consequences of these choices? SGML was and is a hugely successful data
> model/format, but it only really took off when it turned hypermedia...
>
> it's hard to imagine how it could have happened without a ubiquitous
> hypermedia format (based on SGML) making itself known and recognizable.
> i think is actually the much more interesting analogy to think about
> instead of text/plain...
>

I guess text/sgml;profile=html would have worked :)

  pa


>
> cheers,
>
> dret.
>
>