Dewey explanation

gistfile1.txt

A very good question (and not an easy one to answer). The short answer
would be: Language _is_ an element of the domain to be described (Dewey
concepts), so a different language should generate a different URI,
because it describes a separate instance of a concept. A longer answer:

My basic premise here was that a URI like http://dewey.info/class/641/
should indentify class 641 across all versions/languages of the DDC, not
just the most current version or a multilingual version. Why?

1. Labels can change over time for a given class, which could lead to
inconsistencies with the SKOS model. For example, at one point in time
class 210 had the prefLabel "Natural theology"; now it has the prefLabel
"Philosophy & theory of religion" (which reflects changes to its
semantics as well). This would lead to problems when hanging them from
one concept:

<http://dewey.info/class/641/>
       skos:prefLabel "Natural theology"@en;
       skos:prefLabel "Philosophy & theory of religion"@en;
...
       skos:prefLabel "Religionsphilosophie, Religionstheorie"@de.

2. The prefLabel is not the only relationship that might be dependent on
the concept language. And many of these relationships are not used with
plain literals in object position that can be disambiguated with a
language tag. Semantic relationships may be different for a concept in
the German version of the DDC. Example: 220.5312 Luther-Bibel und
Revisionen is a concept that, because of an expansion, only exists in
the German edition. There has to be a way to identify this class as a
German edtion concept, not only as a Dewey concept that happens to only
have a German caption.

3. One could argue that this would not be a relevant counter-argument if
translations where 100% interoperable (i.e., 220.5312 might one day be
included in the English edition as "Luther Bible and revisions".
(Interoperability in this case would mean that no other translation or
the English edition could have claimed this number to coin a different
concept.) But translations are not always perfectly synchronized. So
http://dewey.info/class/641/2008/01/03/ in Portugese could in fact be a
translation of an earlier version of the English concept, e.g.
http://dewey.info/class/641/2005/08/09/about.en (that might have been
updated with different index terms, different semantic relationships and
so on in the meantime).

4. Finally, having different identifiers for the same concept in a
different language, or, more precisely, for a concept with the same
Dewey number, makes it possible to answer very useful questions like:

"Which concepts exist in the German but not in the English edition?"

---

The compromise here is to use language as part of the document URIs (as
a dimension of the representation), not as part of the "abstract" URIs.
So, if you want to refer to a class, or timestamped version, you can do
so in an abstract way:

http://dewey.info/class/641/      -> 303 See Other:
http://dewey.info/class/641/about
http://dewey.info/class/641/2003/ -> 303 See Other:
http://dewey.info/class/641/2003/about

A 303 points a user agent to the generic document which is "/about".

Whereas when you want to refer to a specific language or format, you
have to use a specific URI for an information resource, e.g.,
http://dewey.info/class/641/about.de or
http://dewey.info/class/641/2003/about.de. So language _is_ recognized
as part of the domain, but only as part of representations, not of
concepts.

> See how multiple skos:prefLabel assertions can be made using
> the same subject? To illustrate why I think this is important
> consider how someone may use the resources at dewey.info:
>
>     <http://openlibrary.org/b/OL11604988M> dct:subject
> <http://dewey.info/class/641/> .
>
> If we follow our nose to http://dewey.info/class/641 we will
> get back some RDF, but the description we get isn't about the
> subject <http://dewey.info/class/641/> so what are we to make
> of the above assertion?

Going back the the premise, I thing the question is here: What is
http://dewey.info/class/641/? Is it a SKOS concept? If we analyse a
couple of triples from the response we can determine what a user agent
might learn from the answer of the service:

<http://dewey.info/class/641/2009/08/about.en>
   dct:isVersionOf <http://dewey.info/class/641/> .
<http://dewey.info/class/641/2009/08/about.de>
   dct:isVersionOf <http://dewey.info/class/641/> .
...
<http://dewey.info/class/641/2009/08/about.es>
   dct:isVersionOf <http://dewey.info/class/641/> .

It is true that http://dewey.info/class/641/ is never mentioned in
subject position, but it is in object position several times. So an
agent might deduce the following about http://dewey.info/class/641/ from
the response:

<http://dewey.info/class/641/>
   dct:hasVersion <http://dewey.info/class/641/2009/08/about.en> ;
   dct:hasVersion <http://dewey.info/class/641/2009/08/about.de> ;
...
   dct:hasVersion <http://dewey.info/class/641/2009/08/about.es> .

And this coincides with what we get if we use a SPARQL query directly:

DESCRIBE <http://dewey.info/class/641/>

(http://tinyurl.com/nrlsqm)

Query result:

<http://dewey.info/class/641/> rdf:type skos:Concept ;
   dct:hasVersion <http://dewey.info/class/641/2009/08/about.en> ,
                  <http://dewey.info/class/641/2003/08/about.de> ,
                  <http://dewey.info/class/641/2009/08/about.fr> ,
                  <http://dewey.info/class/641/2009/08/about.es> ,
                  <http://dewey.info/class/641/2009/08/about.sv> ,
                  <http://dewey.info/class/641/2009/08/about.pt> ,
                  <http://dewey.info/class/641/2009/08/about.ru> ,
                  <http://dewey.info/class/641/2009/08/about.zh> ,
                  <http://dewey.info/class/641/2009/08/about.ar> ;
   skos:notation "641"^^"schema-terms/Notation" .

I agree that it is somewhat misleading to not give this information when
dereferencing http://dewey.info/class/641/. So do you think the results
of a DESCRIBE query should always be included for any given URI in a
linked data service? Should (all) triples be included also where the URI
is used in object position? Would you think it is misleading to give
more information?

The class http://dewey.info/class/641/ is not so much a single concept
but a set, an aggregation of all instances of this class. This might be
comparable to the notion of a work in FRBR. A work is very much an
aggregation of manifestations; a "work set". So my thinking was to
respond to such a request by returning all versions that make up this
set. The most current version could be obtained by
http://dewey.info/class/641/current/ or similar.


> Another unrelated thing I noticed is that the RDFa doesn't
> seem to be usable by the RDFa Distiller:
>
>     http://tinyurl.com/nm8lfa

The problem here is that pyRdfa doesn't seem to send the correct Accept
header. Since dewey.info defaults to RDF/XML if it doesn't see
"text/html" or "application/xhtml+rdfa" in the request, pyRdfa doesn't
see any RDFa at all. You have to skip conneg and use the URL for the
HTML-specific resource directly, e.g.
http://dewey.info/class/641/about.html.

http://tinyurl.com/kjpxmt