RE: RDA and ranges

There may not be a big advantage between rdvocab:title and dct:title, but there may be a semantic one, albeit subtle. I'm not arguing that there is, but you could always rdvocab:title rdfs:subPropertyOf dct:title to reconcile the issue... and it would be nice to shorten the XML namespace prefix to rdv: instead of rdvocab:

 

Andy.

 

From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On Behalf Of Ross Singer
Sent: Wednesday, August 18, 2010 09:06 AM
To: Dan Brickley
Cc: Karen Coyle; public-lld@w3.org
Subject: Re: RDA and ranges
Importance: Low

 

Karen, this is a useful visualization.


I mainly agree with Dan, I don't see the big advantage to rdvocab:title and I see the major downside of it being that most agents know dcterm:title (since, let's face it, there isn't a tremendous amount of inferencing going on in linked data).


I've told you before my personal beef with the RDVocab-isms of titleProperManifestation and chronologicalDesignationOfFirstIssueOrPartOfSequenceManifestation, cataloguersNoteWork, etc. but I'll repeat them here.  We have these property that are effectively the same thing but require an exponential increase of complexity on the part of both the producer and consumer.  I notice that these properties now actually have domains, making their utility even more questionable.

 

Again, since most agents won't have the capacity to know that titleProperManifestation is a subproperty of titleProper (which is subproperty of rdvocab:title), they'll have to look for: titleProper, titleProperManifestation, titleProperExpression(?), titleProperWork(?) (these last two don't exist and I don't know if that's intentional or a work in progress - there is, for example, "title", "titleManifestation" and "titleOfTheWork").

 

This sort of defeats the purpose of RDF, though.  Rather than duplicating (quintupling, really) every property to infer the domain, it would be much easier on both ends to simply have:

 

_:a

  rdvocab:titleProper "A proper title"@en;

  rdf:type frbr:Manifestation.

If the application of the properties is different depending on the class of the resource it is being asserted to, then I think that can be worked out in documentation or an application profile or something.

 

-Ross.

 

On Wed, Aug 18, 2010 at 3:01 AM, Dan Brickley <danbri@danbri.org> wrote:
>
> On Wed, Aug 18, 2010 at 2:09 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> > There's been something tickling my brain for a bit, so I sat down to try to
> > draw up a diagram. Essentially, the question is: what is the domain & range
> > of an RDA property? Then I began to wonder what is the domain and range of a
> > property based on RDA but not bound to a FRBR domain?
> >
> > My unfinished diagram is here:
> >
> > kcoyle.net/domainsranges.pdf
> >
> > and I now realize that title isn't the best example to use. But the key
> > element, in my mind, is that the RDA guidance rules both guide the metadata
> > creator and define the range of the element. Those ranges are inherent in
> > the rules but have not been extracted into the registry, in part because
> > many of the ranges are quite complex. In the rules you find how the property
> > is to be structured and what values are valid, which to me is the definition
> > of the range.
> >
> > Note that in the diagram I have only filled in the domain and range at the
> > bottom (most specific) level. That is because I'm not sure what to do beyond
> > that. If we treat the RDA rules as describing the ranges for the properties,
> > then all of the properties, regardless of whether they are bound to FRBR,
> > are very tightly defined (probably what Tom would call ontologically
> > strict). If we wish for other communities to provide guidance rules of their
> > own for the properties, then it becomes hard to think of them as RDA
> > properties. (This is a can of worms that has been a matter of discussion
> > between JSC and the registry.)
> >
> > What I am getting at is that we may need a hierarchy that goes like this
> > (from most specific to most general):
> >
> > 1. RDA + FRBR -- range is as defined in RDA; domain is FRBR entity
> > 2. RDA alone -- range is as defined in RDA; no domain?
> > 3. Property with definition -- range and domain are open
> >
> > I hope I've made some sense here. Although we've discussed whether RDA
> > properties must be bound to FRBR, in fact I think that RDA's definition of
> > the values/ranges is more of a constraint than FRBR.
>
> This is a useful exercise!
>
> Quick question. Going from the diagram alone, it isn't clear to me
> exactly how dcterms:title is more general than rdvocab:title.
>
> * dcterms:title, definition: A name given to the resource.
> * rdvocab:title, definition: A word, character, or group of words
> and/or characters that names a resource or a work contained in it.
>
> >From those definitions alone, it seems that rdvocab:title allows some
> cases that aren't anticipated by dcterms:title, namely when the value
> is a name for a work contained within the main thing we're describing.
>
> I read "a word, character, or group of words and/or characters" as
> approximating the concept of "text", although on a strict reading, it
> seems a little confused as to whether the group of words/characters is
> necessarily ordered. Presumably the ordered group of characters [ "H",
> "a", "m", "l", "t", "e" ] isn't a name given to Shakespeare's Hamlet,
> whereas the ordered group  [ "H", "a", "m", "l", "e", "t" ] is?
>
> If we proceed with this level of nitpicking it'll take forever; is it
> OK to assume "text that" when I see "A word, character, or group of
> words and/or characters that"? In which case, next question is whether
> the text can be a separate entity/resource/thing rather what RDF would
> call a literal. If 'yes', I can't see anything that would be a value
> fitting the dcterms:title definition but fails to match rdvocab:title;
> if 'no', it seems the properties as defined have only partial overlap
> rather than forming a hierarchy.
>
> All that said, your main point seems to be around the RD vocab and
> FRBR, perhaps the DC aspect is a distraction?
>
> cheers,
>
> Dan
>
>
> > kc
> >
> > p.s. I will try to locate some better examples of RDA rules as ranges.
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > ph: 1-510-540-7596
> > m: 1-510-435-8234
> > skype: kcoylenet
> >
> >
> >
>
>
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation™
>
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.