- From: Sarven Capadisli <info@csarven.ca>
- Date: Mon, 03 Aug 2015 16:04:47 +0200
- To: public-openannotation@w3.org
On 2015-07-25 21:25, Robert Sanderson wrote:
>
> Hi Sarven,
>
> One of the considerations here was that you can't have both language and
> datatype associated with the same literal, so we had to pick two
> predicates for recording the information and mint a resource for the
> subject. We went with Content in RDF as it seemed at the time to have
> some legs and fulfilled our requirements. In the Annotation working
> group, we've minted our own class, as it's clear that CNT is abandoned
> and will never reach recommendation status.
I may be mixing up a few things here and hope that you can clarify.
Can you please clarify what those two predicates you are referring to?
I'm only aware of oa:hasBody. Unless you meant something completely
different.
oa:hasBody doesn't have a range, and
http://openannotation.org/spec/core/core.html#BodyEmbed talks about /
examplifies it being purposed as an ObjectProperty. Did I understand
this correctly, or is it possible to have oa:hasBody as a
DatatypeProperty? Using the example from my first email, would this be okay:
<div property="oa:hasBody">
<p>foo</p>
</div>
> We went with dc rather than dcterms because of the ranges.
> dcterms:format has a range of a resource of class
> dcterms;MediaTypeOrExtent. We thought this was overkill for the 95% use
> case of just recording the media type of the content, and dc elements
> has no such requirement. Ditto dcterms:language and
> dcterms:LinguisticSystem, versus dc:language.
>
> While the information in RDFA is not very interesting to a human reader
> of the page, RDFA is not intended for humans :) Once that annotation
> has been pulled out of the page and made available separately as its own
> resource, that information is very important so clients know how to
> render it to the user.
Aside: IMO, a good HTML+RDFa markup practice is to minimize, if not
eliminate the differences in information that's given to both humans and
machines. If machine-processing is the sole concern, there are other RDF
formats, e.g., N-Triples, which are more suitable for the job. Hence, if
one is committing to HTML+RDFa, it is arguably preferable to cut down on
hidden markup (i.e., acting as secondary metadata) which is only
"visible" to the machines. In a way, RDFa is closely tied to
human-friendly documents.
> Hope that helps!
>
> Rob
>
Thanks a lot for your feedback!
> On Sat, Jul 25, 2015 at 9:16 AM, Sarven Capadisli <info@csarven.ca
> <mailto:info@csarven.ca>> wrote:
>
> Hi all,
>
> http://openannotation.org/spec/core/core.html#BodyEmbed suggests to
> use dc:format. I was wondering whether it'd be okay to use
> dcterms:format instead? My reasoning is simply that I predominantly
> use dcterms, and don't wish to introduce dc (elements). Tough luck?
>
> I find cnt to be (unnecessarily?) cumbersome in RDFa when used with
> oa:hasBody and cnt:ContentAsText. Use case: representing comments on
> a webpage which include HTML. This forces me to add markup that's
> only for machine consumption i.e., <span property="dcterms:format"
> content="text/html"></span></div>, and possibly even <span
> property="cnt:characterEncoding" content="utf-8"></span>, <span
> property="dcterms:language" content="en"></span>. I think we can
> agree that the above information is not very "interesting" to a
> human-reader on a webpage.
>
> Leaving dcterms:format would mean that the consumer has to further
> process - I'm okay with this if there is no sensible alternative.
>
> Are there any workarounds people employing? How does the following look:
>
> <div rel="oa:hasBody">
> <div about="http://example.org/foo"
> property="dcterms:description" datatype="rdf:HTML">
> <p>foo</p>
> </div>
> </div>
>
> [Note that the rdf:HTML datatype is left as non-normative in RDF
> 1.1: http://www.w3.org/TR/rdf11-concepts/#section-html ]
>
> Thoughts?
>
> Thanks,
>
> -Sarven
> http://csarven.ca/#i
>
>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
-Sarven
http://csarven.ca/#i
Received on Monday, 3 August 2015 14:05:20 UTC