-----Original Message-----
From: DCMI Architecture Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: zondag 23 augustus 2015 18:40
To: [log in to unmask]
Subject: Re: dcterms:type and SKOS
> I have mixed feelings about the ranges in dcterms. On one hand,
> without them one has no guidance on usage/expectations, and we know that
> it's not easy to work with properties whose ranges can be either literals or IRIs.
> On the other hand, not everyone has IRIs (yet) for their data.
> (cf. the ISO language codes, ISBNs, etc.) The saving grace is that for some
> common properties the 1.1 vocabulary exists, so if one needs to use a literal for
> "type" one can use dce:type rather than dcterms:type.
If you want a range declaration for some of the dcterms-properties to prevent mixing literals and resources and urge people to use dce-properties for use with literals, then why is rdfs:Class any better than skos:Concept? Alternatively one could consider something like owl:Thing. Is that the direction of your thinking? -j
>
> As far as the use of SKOS is concerned, the creation of a formal
> thesaurus sounds much more complicated than it is. Instead of
> publishing a list of literals, people should IMHO be stimulated
> wrapping the literals in concepts.
> Well, in spite of your HO, you have no control over what others choose to do.
> While SKOS is not difficult, we can't make others use it if they decide not to.
> However, if we want Dublin Core to be useful throughout the web of data, we
> need to keep it as unconstrained as possible.
kc
>
> I believe that from a practical perspective this method is easier
> than publishing formally defined Vocabulary Encoding Schemes (VES),
> which the DC-standard seems to prescribe wherever literals are used
> as property values (independently of whether this is actually done at
> a significant scale). Using a VES, one can write things like
> dcterms:subject "Napoleon"^^ex:myVES. Using simple tooling one could
> instead put all the literals in an Excel-sheet and import them in a
> thesaurus, so that you could then write dcterms:subject
> ex:NapoleonConcept. Subsequently, others could relate their
> terminology to the one in the thesaurus, using standard relations,
> which is not possible with a VES.
>
> Different communities could use different concept schemes (thesauri)
> in their APs to restrict the property values of the same properties.
> -j
>
>
> -----Original Message----- From: DCMI Architecture Forum
> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
> Sent: dinsdag 18 augustus 2015 19:49 To:
> [log in to unmask] Subject: Re: dcterms:type and SKOS
>
> Jan,
>
> I believe I understand your use case, but it is only one possible use
> of Dublin Core terms, and I feel it is essential that DC terms be
> suitable for a wide variety of communities. What makes dcterms one of
> the most used vocabularies in the LOV dataset [1] is precisely its
> flexibility. Limiting dcterms:subject to skos:Concepts would likely
> discourage communities whose tradition does not include the creation
> of formal thesauri.
>
> It makes sense to have an agreement with your data sharing partners
> about the expected values for properties. This is the basis for the
> DCMI work on application profiles [2][3] which extend the basic
> vocabulary to meet specific needs. APs also relate to work in
> progress on RDF validation [4][5]. The "best of all possible worlds"
> would be a very general and flexible vocabulary that can be
> integrated into specific applications but that also allows
> interconnection between disparate communities. Machine-actionable
> application profiles could make that possible.
>
> As for the list of terms in the DC type vocabulary[9] - I see it as
> being rather naive. Library of Congress not only has its own list of
> genres [6], it has a list of lists of genres [7]. The total number
> must be in the high three digits. I also find interesting the
> FaBio/CiTO list, that is primarily based on academic articles[8].
> "Type" is definitely a concept within a context, so will be defined
> differently in different communities, as we see already.
>
> kc
>
>
> [1] http://lov.okfn.org [2]
> http://dublincore.org/documents/singapore-framework/ [3]
> http://dublincore.org/documents/profile-guidelines/ [4]
> http://wiki.dublincore.org/index.php/RDF_Application_Profiles [5]
> http://www.w3.org/2014/data-shapes/wiki/Main_Page [6]
> http://id.loc.gov/vocabulary/genreFormSchemes/marcgt.html [7]
> http://id.loc.gov/vocabulary/genreFormSchemes.html [8]
> http://sempublishing.sourceforge.net/ [9]
> http://dublincore.org/documents/dcmi-type-vocabulary/
>
> On 8/17/15 12:56 PM, Jan Voskuil wrote:
>> Hi Dan, and Karen, I've been thinking about the valuable point you
>> raise --- thanks for doing so.
>>
>> Before going on, let me first ask: would you agree on the basic
>> premise on which I started this discussion, namely, that the range
>> of dcterms:type should not be rdfs:Class?
>>
>> The next question is about declaring the range of dcterms:subject
>> and dcterms:type to be skos:Concept. I see your point about
>> usefulness. I think this has to do with two fundamentally different
>> approaches to the notion of "aboutness": the systematic approach
>> versus the encyclopedic approach.
>>
>> In the encyclopedic approach, an article is seen as a set of
>> statements about some RWO or FWO. The set of articles is flat,
>> without a structure (apart from alphabetic ordering by the name of
>> the RWO). This idea is driving Wikipedia and DBPedia and is part of
>> their success and effectivity.
>>
>> In the systematic approach, articles are thought of as being about
>> "subject headings". The subject headings together form a rich
>> associative structure, in which the subject headings are connected
>> to each other, which yields groupings that make sense from some
>> perspective or for some purpose. This implies a notion of
>> metamodeling. SKOS intends to capture this notion in a manner as
>> concise and simple as possible.
>>
>> Is the systematic approach useful? That is quite a question to
>> pose. It is certainly easy to make fun of (sometimes overly
>> ambitious) attempts made in the past. See Borges' famous and
>> hilarious taxonomy of animals in terms of those that belong to the
>> Emperor, those drawn with a very fine camel hair brush, and some
>> other such categories (see [1]). Another fundamental critique of
>> hierarchical schemes such as DDC and UDC is the " rhizome metaphor"
>> (see [2] and [3]). A beautiful, thoroughly non-philosophical
>> account of the development of ideas underlying the systematic
>> approach is [4]. That said, I think it is fair to say that the
>> systematic approach has its usefulness, warts and all. Probably
>> especially so in specific, delimited domains.
>>
>> Concluding, the statement that something is about something can
>> mean two fundamentally different things, depending on the spirit in
>> which of the two approaches the statement is made.
>>
>> There are two options for dcterms:subject (and dcterms:type).
>>
>> A. We leave the choice open to the user by not specifying a range
>> for dcterms:subject. The property can mean two different things
>> depending on the context in which it is used: a simple case of
>> polysemy or even homonymy (or punning if you like).
>>
>> B. We urge users to make the choice explicitly by declaring
>> dcterms:subject to have skos:Concept as range. In that case, one
>> would say that the Wikipedia article has foaf:focus Bill_Clinton
>> (to which it does not bear the dcterms:subject relation), while the
>> biography fits under a particular subject heading, so that it bears
>> the dcterms:subject relation to that heading, which in turn bears
>> the foaf:focus relation to Bill_Clinton.
>>
>> It seems to me that option B is to be preferred, independent of
>> your commitments towards either one of the two approaches towards
>> aboutness.
>>
>> The reason for this is data quality. In the old days, we were used
>> to, say, put the customer's date of birth in the field called
>> telephone number because that field was not used by applications
>> anyway. And everybody was happy. Now we put our data models on the
>> Web, hoping to achieve unprecedented levels of interoperability at
>> almost no cost at all. We do this in the realization that we cannot
>> expect every data source to always adhere to every minute detail of
>> the model. This is what Antoine pointed out previously: the
>> philosophy schema.org, which says: " In the spirit of "some data is
>> better than none", we will accept this markup [which does not
>> comply to expectations, JV] and do the best we can."
>>
>> This also means that refined data is better than some data. In
>> other words, the more careful data sources are about which
>> particular properties they use, the more value others can extract
>> from them. (Of course, up to a point, where the distinctions become
>> so subtle that they become difficult to understand.)
>>
>> Under option B, a data source that uses dcterms:subject to relate
>> articles to RWOs (and maybe even foaf:focus to relate articles to
>> subject headings) is not a problem. We can happily use the data
>> source, and even manipulate it using a range of methods to make it
>> as valuable as possible. At the same time, however, a "high
>> quality" data source that does make the distinctions as intended
>> yields the same value or more at lower cost. Under option A, there
>> is no real sense in which this data source is different in
>> quality.
>>
>> So, to drive home the point I am (albeit somewhat laboriously)
>> trying to make: in view of the existence and broad use of
>> foaf:focus, it makes sense to restrict dcterms:subject and make the
>> two disjoint in range. As opposed to leave it completely open to
>> use dcterms:subject either as a synonym of foaf:focus or as
>> something else.
>>
>> I hope I am not ranting. Does this make any sense? -Jan
>>
>>
>> [1]
>> https://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowled
>>
>>
ge [2] https://en.wikipedia.org/wiki/Rhizome_(philosophy)
>> [3] http://rhizomik.net/html/rhizome/ [4]
>> http://www.catalogingtheworld.com/
>>
>>
>>
>>
>>
>> -----Original Message----- From: DCMI Architecture Forum
>> [mailto:[log in to unmask]] On Behalf Of Dan Matei
>> Sent: maandag 17 augustus 2015 11:46 To:
>> [log in to unmask] Subject: Re: dcterms:type and SKOS
>>
>> -----Original Message----- From: Jan Voskuil
>> <[log in to unmask]> Date: Mon, 17 Aug 2015 07:55:22 +0000
>>
>>>
>>> To express the relation between a metamodelling concept
>>> (":NapoleonConcept") and the RWO/FWO (":NapoleonBonaparte"),
>>> foaf:focus fits the bill quite nicely. (((---On a side note: I
>>> think that there should be an equivalent of this property within
>>> the SKOS-namespace.---)))
>>
>>
>> I have difficulties to understand the practical usefulness of the
>> distinction "NapoleonConcept" vs. RWO/FWO "NapoleonBonaparte" :-(
>>
>> How "NapoleonConcept" fits in the definitions:
>>
>> S: (n) concept, conception, construct (an abstract or general idea
>> inferred or derived from specific instances)
>> http://wordnetweb.princeton.edu/perl/webwn?s=concept&sub=Search+WordNe
>>
>>
t&o2=&o0=1&o8=1&o1=1&o7=&o5=&o9=&o6=&o3=&o4=&h=
>>
>> or
>>
>> A SKOS concept can be viewed as an idea or notion; a unit of
>> thought. However, what constitutes a unit of thought is subjective,
>> and this definition is meant to be suggestive, rather than
>> restrictive. http://www.w3.org/TR/skos-reference/#concepts
>>
>> ?
>>
>> Of course my idea of "Monica Bellucci" differs (somehow) of the
>> real Monica Bellucci :-) However...
>>
>> Yes, I can see the usefulness of the distinction between different
>> catalographic identities (as subjects), such as:
>>
>> Mark Twain vs. Samuel Langhorne Clemens
>>
>> Charles Lutwidge Dodgson vs. Lewis Carroll
>>
>> Enea Silvio Piccolomini vs. Pius II
>>
>> or even:
>>
>> Bill Clinton (as himself) Bill Clinton (as governor of Arkansas)
>> Bill Clinton (as president of USA)
>>
>> But to consider them concepts ? Useful ?
>>
>> Dan Matei
>>
>
> -- Karen Coyle [log in to unmask] http://kcoyle.net m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|