JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-RDA Archives


DC-RDA Archives

DC-RDA Archives


DC-RDA@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-RDA Home

DC-RDA Home

DC-RDA  March 2008

DC-RDA March 2008

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: A possible strategy for our literals/non-literals conundrum ...

From:

Mikael Nilsson <[log in to unmask]>

Reply-To:

List for discussion on Resource Description and Access (RDA)

Date:

Tue, 25 Mar 2008 23:10:56 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (162 lines)

tis 2008-03-25 klockan 13:29 +0100 skrev Thomas Baker:
> > Property: duration
> > data: "27 min."
> 
> There are two ways to express this in RDF:
> 
> 1. If rda:duration were defined with a literal range:
> 
>     R rda:duration "27 min." .
> 
> 2. If rda:duration were defined with a non-literal range:
> 
>     R rda:duration _:x .
>     _:x rdf:value "27 min." .

Insert Rob's typed literal as case 3 here:

3. If rda:duration were defined with a typed literal range

     R rda:duration "27 min"^^rda:DurationType

where rda:DurationType is an RDF Datatype, and would be, more or less,
specified using a syntax pattern, such as

[0-9]+[ ]?(h|min|sec)

(allowing for integer hours, minutes, or seconds, such as "2h", "29 min"
and "3420sec" etc). Each valid literal instance of this pattern needs to
be given an interpretation (= "value" in the "value space"), in this
case something like "an interval of time, measured in whole seconds"

Note that the pattern and the interpretation needs to be predefined -
there is no room for extensibility in typed literals.

A second comments has to do with what the "rules" say. I'd like us to be
*extremely* careful to make sure we draw the line between what's in a
property definition, and what is part of an application profile.

For example, assume we choose pattern 2 above. The property definition
would be something along the lines of

URI:        rda:duration
Label:      Duration
Definition: The duration of a resource
Range       rda:Duration

where rda:Duration is the class of all durations (compare, for example,
http://dublincore.org/documents/dcmi-terms/#terms-accrualPeriodicity).

It is up to the class rda:Duration to define how Durations are
represented. 

Now, with this definition, all these patterns are perfectly ok:


1. URI for an instance of rda:Duration:

	R rda:duration <http://example.org/Durations/234451>


2. Blank node with rdf:value:

	R   rda:duration _:x
	_:x rdf:value "29 min"

3. Blank node with other properties

	R   rda:duration _:x
	_:x rda:hours "0"^^xsd:integer
	_:x rda:minutes "29"^^xsd:integer

etc etc.

However, the RDA rules may say: "This property is to be used with NO
URI, and with a *single* rdf:value property (=value string) containing a
string formatted according to.....". This will make only case 2
acceptable.

This rule is best made part of an application profile. As long as the
properties and classes are well-defined, they will still allow for
application profiles that say "Use one of the following URIs for
durations: ..." or "NEVER use blank nodes" or "Use the following more
precise properties of the rda:Duration object", etc etc.

So, the question we need to ask ourselves is "what different kinds of
application profiles do we want to enable?". Tom touched the issue when
he mentioned dcterms:date - it was decided that application profiles
using this property must limit themselves to literal values, in the
interest of increased interoperability. For many other properties, the
choice was the reverse. And for one, dcterms:title, the choice was (is?)
a very hard one....


> The "x" could be one of the following:
> 
>    a. a blank node
>    
>    b. a deliberately assigned URI, for example a member of 
>       a hypothetical Vocabulary Encoding Scheme for durations 
>       (not that this would necessarily be a good idea!)
>    
>    c. a unique URI automatically generated by software in order to 
>       make it a "named node", which is easier to process than a 
>       blank node.
> 
> Of the three options, "a" is controversial, as Jon points out
> (citing Ian Davis's blog), option "b" would take extra work
> (perhaps unnecessarily), and "c" can straightforwardly be
> automated.

Per my reasoning above, these choices must be left to the application
profile designer. We should not care about the pros and cons of blank
nodes here, but certain applications will care. We should only care
about what choices we want to *enable*.

> So to summarize, the fact that a duration will be represented
> using a literal does not mean that rda:duration needs to have
> a literal range.

Exactly. But the above should read: "the fact that a duration will be
represented *in the RDA application profile* using a literal does not
mean that rda:duration needs to have a literal range". Maybe we want to
enable other application profiles that make different choices. Or maybe
we don't. The justification must be found elsewhere.

We're facing a generalization issue - extracting properties from a
pre-existing application profile, and trying to make them as useful as
possible to a broader audience. That's where we need to think hard....
and where we need the use cases.

> 
> And it is important not to confuse the literal/non-literal
> issue with the issue of serialization formats.  The example
> above could in principle be serialized in a very simple XML
> format with
> 
>     <duration>27 min.</duration>
> 
> and this could still correspond to the following non-literal
> representation in RDF:
> 
>     R rda:duration _:x .
>     _:x rdf:value "27 min." .
> 
> as long as the definition of the format were to make clear
> that duration is intended to represent a non-literal and the
> mapping to a correct RDF triple representation were encoded
> in a GRDDL transform (or similar sort of conversion algorithm).

Exactly right. And if we cared only for "RDA applications", the RDF
variant would likely be completely uninteresting. The interesting stuff
happens when the generated RDF triples meet other metadata. Will it
blend? [1] 

/Mikael

[1] http://www.willitblend.com/

-- 
<[log in to unmask]>

Plus ça change, plus c'est la même chose

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
August 2012
July 2012
May 2012
April 2012
March 2012
February 2012
January 2012
October 2011
September 2011
August 2011
June 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
June 2010
February 2010
January 2010
December 2009
November 2009
October 2009
June 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
August 2007
July 2007
June 2007
May 2007
April 2006
February 2006
January 2006
December 2005


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager