RE: @value/@type/@language combination

Rob,

quick question. Are you looking for a JSON-LD only solution or does this have to be visible at the abstract RDF level as well? If not, you could work around this issue with @index.


--
Markus Lanthaler
@markuslanthaler



------------------- Original Message -------------------

Stian: You could argue that, and you might technically be correct, but I think there's a lot of people who would like to say that a web page is in a particular language :)  


The options we're considering:

1.  Drop @type,  keep @language, and require in the specs rather than the RDF that if an @value starts with < and ends with > then it MUST be [X]HTML.
2. Drop @language, keep @type, and put language in the HTML using xml:lang, as per Gregg and what we did with annotations in EPUB: http://www.idpf.org/epub/oa/#h.fbvcg1ft34rp
3. Use ContentAsText as per Stian (and Markus with a little tweaking) when we need HTML and literals when we don't.


Given that the majority of use cases revolve around multiple languages in a UI, the current resolution we have is option 1.  The reasoning:

* @language is unlikely to repeat in a list of values, whereas all values are likely to be in either HTML or plaintext but less likely to be mixed. This makes @language more useful as a discriminator for which value to use. Otherwise, you have to parse the language out of the XML for all values just to throw all but one away. That's very inefficient. 

* Keeping @language is internally consistent with other uses of literals. We only type literals in the context, not in the recommended serialization. Especially as HTML is only usable in a limited number of fields compared to regular literals, there would be a lot of special cases to have to deal with.

* Allowing both nodes and literals is messy for the range of the properties, and very inconsistent as to what the clients need to process.  Requiring just ContentAsText is really klunky in this situation (compared to the body of an Annotation, for example, when it makes sense)

* A browser can just throw the content into HTML and not care whether it's a literal or an HTML snippet. It'll come out as expected.

* The check for [X]HTML could be as simple as value[0] == '< and value[-1] == '>', with the very edgey edge case of a non HTML literal requiring an extra space at the end of the value.

Rob


On Thu, Aug 14, 2014 at 12:51 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:
One could argue that as soon as you have used a different datatype it is no longer text in that language. English language does not have <p> as one of it's constructs.
I would probably have used Content-in-RDF for that use case. XML literals in RDF are fragile and a relic of the RDF/XML days.
On 14 Aug 2014 01:07, "Gregg Kellogg" <gregg@greggkellogg.net> wrote:
On Aug 13, 2014, at 4:31 PM, Robert Sanderson <azaroth42@gmail.com> wrote:



Dear all,

We have a use case that would require all three of @value, @type and @language for a single resource, which is not allowed according to the specification (eg section 8.3)

We would like to use either plain literals (and hence @value/@language) or X/HTML in the same space to allow basic styling and linking within the text.  We want to do this in a way that doesn't involve introspection of the value to determine whether it's text/plain or text/xml if at all possible.

For example:

{
  "description": {
    "@value":"<p>Some <b>description</b></p>",
    "@type": "rdf:XMLLiteral",
    "@language" : "en-latn"
  }
}

Is there any existing best practice for how to accommodate this?

Note that the RDF data model allows literals to have either a datatype or a language, but not both. JSON-LD is just being consistent here.

In most applications (e.g., RDFa markup), the language is included in the markup:

{
  "description": {
    "@value":"<p lang="en-latn">Some <b>description</b></p>",
    "@type": "rdf:XMLLiteral"
  }
}

Of course, it could be that you'd like to use @container=language, to index into different markup, but as you see, this isn't supported either in RDF or JSON-LD.

Gregg

Thanks!

Rob


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305





-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305

Received on Thursday, 14 August 2014 17:03:03 UTC