On 21 Mar 2010, at 00:37, Kingsley Idehen wrote:
I got the idea of something like this:
<http://example.org/>
a foaf:Document ;
rdfs:label "Article"@en , "Статья"@ru ;
dcterms:title "Article"@en , "Статья"@ru ;
dcterms:creator <http://example.org/id/joe> ;
dcterms:created "2010-03-04"^^xsd:date ;
dcterms:hasVersion <http://example.org/index.en.html> ,
<http://example.org/index.ru.html> .
<http://example.org/index.en.html>
a foaf:Document ;
rdfs:label "Article"@en ;
dcterms:title "Article"@en ;
dcterms:creator <http://example.org/id/joe> ;
dcterms:created "2010-03-04"^^xsd:date ;
dcterms:language <http://www.lingvoj.org/lang/en> ;
dcterms:hasVersion <http://example.org/index.ru.html> .
<http://example.org/index.ru.html>
a foaf:Document ;
rdfs:label "Статья"@ru ;
dcterms:title "Статья"@ru ;
dcterms:creator <http://example.org/id/joe> ;
dcterms:contributor <http://example.org/id/jane> ;
dcterms:created "2010-03-17"^^xsd:date ;
dcterms:language <http://www.lingvoj.org/lang/ru> .
Joe is the author of the original article, and he's credited as
dcterms:creator. Jane is the translator, she is mentioned as
dcterms:contributor for the Russian resource.
Problem: the Article and the Document (the resource at the URL) are
distinct. Think "Book" and "Story in the Book" they are two distinct
things with different characteristics (properties) that are
connected by a relation.
This is debatable. It rings true in *some* cases (for example, if a
newspaper article appears both in print and on the web, or indeed
books). But for text that is only written for the purpose of being
published on the web, having separate URIs for the “article” and
the “web document containing the article” is overanalysing.
For example, if I publish a blog post at </blog/2010/03/21/
mypost.html>, then it would be overkill to create a separate URI </
blog/2010/03/21/mypost.html#this> to distinguish between the “web
document containing a blog post” and the “blog post as such”. One
URI (mypost.html) is enough. The only reason for having separate URIs
would be if the author actually wants to assert different properties
about the two things, but that doesn't seem likely in the typical web
publishing case.
(It might be a good idea to mint a URI for the *topic* (or topics) of
the article, for example if the topic is a person or project or event.
This allows me to make statements about this person/project/event,
which clearly has different characteristics than the article, so it
cannot have the same URI. But that's just a corollary to the old
linked data axiom that the topic of a document is a different entity
from the document itself.)
Best,
Richard
dcterms:created for the canonical URI reflects the creation date of
the
original article. For the translation, it's substituted with the
date of
translation.
I'm not sure if we could also say that
</index.ru.html> dcterms:hasVersion </index.en.html> .
I guess it depends on one's reading of the DC spec, probably nobody
would die if this triple was included, but here I omitted it for
extra
precision.
The Lingvoj ontology[1] also has provisions for describing
translations
as resources in their own right, but it's a bit beyond the topic
here.
As for dcterms:hasFormat, I don't think it can be used here, but if
we
also had a PDF version of the article, we could write:
</index.en.html> dcterms:hasFormat </index.en.pdf> .
</index.ru.html> dcterms:hasFormat </index.ru.pdf> .
(and vice-versa)
Further corrections/additions welcome.
[1] http://www.lingvoj.org/ontology.rdf
For simplicity sake, just at "#this" to the following URLs and then
reevaluate the model i.e, <http://example.org/index.en.html#this>
which is the primary resource (a representation of the document
which is basically a container) associated with a secondary resource
(a representation of what the document is about). At the current
time, your modeling discards the container i.e., treats resource
"index.html" as none existent by describing it using properties of
its content.
--
Regards,
Kingsley Idehen President & CEO OpenLink Software Web:
http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
