Re: CFC: Basic Roles Proposal text vs. url as a default

A separate issue

> On 28 Aug 2015, at 24:09 , Doug Schepers <schepers@w3.org> wrote:
> 

<skip>

> | 2. SHOULD use the same construction for tags as other roles
> 
> You seemed to allude that this means we have the same construction for Semantic Tags and Tags; is that right? That consistency would be good.
> 
> But your examples seems to show pretty much the opposite of what I'd suggested last week, having the text value be the default (which I thought we'd agreed on):
> 
> Tag
>  "body": {
>    "role": "tagging",
>    "content": {"text": "tag1"}
>  }
> 
> Semantic Tag
>  "body": {
>    "role": "tagging",
>    "content": "http://example.org/tag1"
>  }
> 
> Whereas I'd have expected something like this:
> 
> Tag
>  "body": {
>    "role": "tagging",
>    "content": "tag1"
>  }
> 
> Semantic Tag
>  "body": {
>    "role": "tagging",
>    "content": {"url": "http://example.org/tag1"}
>  }
> 
> Clearly, I'm missing something… can you explain?
> 


At the moment we have several types of bodies: pure texts, Web resources (the latter essentially identified by a URI), or an extra object level without a URI (in the RDF terminology those are blank nodes). It may become important to differentiate between these, mainly between a literal and the others; if I use the text "/a/b/c/" as a value, should I interpret this string as a (relative) URI or simply a literal? Without any extra clue this is ambiguous; we have to make the difference somehow.

Taking all the constructions together, including 3.2.3 proposal, we have now the following

- the value of "content" expresses a resource
- the value of "text" expresses a literal

And we can also use, beyond what is in the proposal you quote,

body : {
  "role" : "tagging",
  "text" : "tag1"
}

actually, in this respect (again if we along 3.2.3, too)

body : {
  "role" : "tagging",
  "content" : { "text" : "tagging" }
}

though correct, is an unnecessarily convoluted construction.

Ie, expressing a body with these two properties become unambiguous and easy.

We do have one level of conflation, though: the value of "body" is defined to be either a literal or must be a blank node (3.1.8. of the document). Ie, if I say

"body" : "/a/b/c/"

This is NOT a relative URI, it is just a literal text; for anything that is a web resource

"body" : { … }

must be used (with possible a "id" in the object).

I believe the issue you are raising is whether we use the same conflation for the value of "content". We do have it for "body" because we wanted to make the very simple construction easy, and that is when there is no extra 'stuff' around the body (like roles); this requirement came, for example, when we want to annotate a CSV file by adding annotations to the CSV metadata (by hand). But I believe that keeping the usage of "text" and "content" separated, just like 3.2.3 proposes, is cleaner and does not harm usability because, as I showed, expressing a text with a role becomes just as easy that way.

Because it is a matter of defaults, such discussion can quickly become a bikeshedding issue. I would propose to accept 3.2.3 and (in general, taking the whole discussion on roles) publish a new draft soon with issues clearly marked in the document and getting feedbacks.


Ivan


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704