Re: Dublin Core prefixes in OA

Hi Paolo,

Yes, I understand, but then we have many occurrences of dc11:format, some
of dc11:language, and a few of dc:conformsTo.  I should clarify that I'm
not against it either, I'm just not in favour of a "face trade" that
introduces potential confusion downstream for adopters and implementers
unless there is some gain to outweigh that.

Another concern is the confusion in the JSON-LD serializations, as the
prefix:URI mapping takes place externally to the document containing the
graph (in the context.json resource).  Clearly implementers should look at
and understand that document, but if systems are used to adding in "dc:xxx"
and relying on the context to define dc as elements not terms, then there
would be a huge mess.

That said ... if W3C were to issue a JSON-LD context for the RDFA core
mappings, then we could inherit it as a best practice. That would provide a
substantive benefit, both in terms of understanding and reducing the need
for dereferencing of resources.

If we're going to change the way in which these predicates are *perceived*,
and it's possible to avoid a not-quite-deprecated ontology, then I think we
should fix it all the way through.  Thus my query about using terms:format
and terms:language.

Hope that clarifies!

Rob






On Wed, Jan 15, 2014 at 10:30 AM, Paolo Ciccarese <paolo.ciccarese@gmail.com
> wrote:

> Hi Rob,
> the recommendation in my previous email was just to revise the prefixes,
> not to drop dc for terms.
> At the moment, I am not expecting anything else in the current model to
> change.
>
> Best,
> Paolo
>
>
>
> On Wed, Jan 15, 2014 at 12:11 PM, Robert Sanderson <azaroth42@gmail.com>wrote:
>
>>
>> Tom, and all,
>>
>> I admit to being one of those confused by the ranges for some of the
>> fields in terms.  For example, in Open Annotation we use elements:format
>> for the media type of the resource as a literal.   The range of
>> terms:format is a class, terms:MediaTypeOrExtent, meaning that the object
>> of a triple with the predicate terms:format should be an instance of that
>> class, and thus not a literal.  Similarly dc:language, and
>> dcterms:LinguisticSystem.
>>
>> We use dcterms:conformsTo with oa:FragmentSelector to convey the
>> specification for the fragment in rdf:value.
>>
>> And those are the only uses of elements or terms directly in the model.
>>
>> So, if terms:format "text/html" and terms:language "en" are (somehow,
>> please explain?) possible, then I would be happy to stop using elements,
>> and use dc for terms.  On the other hand, as we currently make much greater
>> use of elements than terms, I'm not in favor of the change as the model
>> stands.  It's "just a prefix" but it's a commonly used and understood one.
>>
>> Rob
>>
>>
>>
>> On Wed, Jan 15, 2014 at 9:37 AM, Thomas Baker <tom@tombaker.org> wrote:
>>
>>> On Wed, Jan 15, 2014 at 10:24:54AM -0500, Paolo Ciccarese wrote:
>>> > He pointed out that while we are absolutely free to pick our own prefix
>>> > definitions, we could consider of aligning them with the prefixes of
>>> the
>>> > RDFa core context: http://www.w3.org/2011/rdfa-context/rdfa-1.1
>>> >
>>> > In particular, that would mean to map
>>> > dc = http://purl.org/dc/terms/
>>> > dc11 = http://purl.org/dc/elements/1.1/
>>> >
>>> > It seems, the DC folks recommended those prefixes to the RDFa WG
>>> because
>>> > they want to slowly deprecate the old 1.1 elements.
>>> >
>>> > It is probably not crucial but, in general, I think it is probably a
>>> good
>>> > idea to align our context with existing ones in the same ecosystem.
>>>
>>> +1 to align with RDFa core context
>>>
>>> As I recall it, the mapping of dc: to /terms/ came about because this is
>>> what the RDFa community preferred at the time, and DCMI had no objection.
>>> After all, they are "just prefixes"... ;-)
>>>
>>> This has, alas, created some confusion for those who had mapped dc: to
>>> /elements/1.1/, though the existence of range-less and ranged properties
>>> in
>>> parallel has been a problem since ranges were introduced in January 2008.
>>>
>>> DCMI "gently promotes" the ranged properties of /terms/ while avoiding
>>> the word
>>> "deprecate" because part of the community feels that the range-less
>>> properties
>>> may in some cases be preferable.
>>>
>>> Tom
>>>
>>> --
>>> Tom Baker <tom@tombaker.org>
>>>
>>>
>>
>
>
> --
> Dr. Paolo Ciccarese
> http://www.paolociccarese.info/
> Biomedical Informatics Research & Development
> Instructor of Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital
> Member of the MGH Biomedical Informatics Core
> +1-857-366-1524 (mobile)   +1-617-768-8744 (office)
>
> CONFIDENTIALITY NOTICE: This message is intended only for the
> addressee(s), may contain information that is considered
> to be sensitive or confidential and may not be forwarded or disclosed to
> any other party without the permission of the sender.
> If you have received this message in error, please notify the sender
> immediately.
>