Re: [Mediann] Ad. "Return Type / String vs Uri" - Issue

Hi Tobias,

I think this is a very good example on how to make a distinction between 
"only string value" and "URI value" on the metadata level, and it would 
be great to have it in a wiki page. However, IMO we are going to provide 
an API which should provide access on a metamodel metadata level. Or to 
put this into a question: If we have a method getSubject, should it return
1) the complete DC-TEXT presentation
2) the completet RDF/XML representation
3) If the input is example 1: the URI. If yes, how does the API "know" 
that it needs to do that?
4) If the input is example 2: the string value. If yes, how does the API 
"know" that it needs to do that?

I think you are aiming for 3) and 4), but I'm not sure.

Best,

Felix

Tobias Bürger さんは書きました:
> Dear all,
>
> I recently had a look at the Dublin Core in RDF recommendation [1] 
> which could provide a solution to the return type issue that we
> discussed in our last telecon [2].
>
> In the recommendation examples to describe Dublin Core metadata in RDF
> can be found [3]. Especially interesting is the use of dcterms:subject
> which in Example 1 points to an URI to identifiy a value. In Example 2 a
> string value and a vocabulary encoding scheme are used (this conforms to
> the example from Werner Bailer which pointed out to established
> classification schemes I guess). This is done using terms from the DCMI
> Abstract Model [4]. In example 3 a language tagged literal is used to
> specify a title.
>
> Perhaps this is a useful best practice for the return type / String vs.
> URI issue.
>
> Do we want to create a WIKI page to discuss this issue? I guess it would
> also be important to discuss for which properties this problem is relevant.
>
> Best regards,
>
> Tobias
>
> [1] Expressing Dublin Core in RDF, http://dublincore.org/documents/dc-rdf/
> [2] http://www.w3.org/2008/12/16-mediaann-minutes.html
> [3] http://dublincore.org/documents/dc-rdf/#app-a
> [3] DCMI Abstract Model, http://dublincore.org/2008/01/14/dcam.rdf#
>
>

Received on Friday, 19 December 2008 08:50:29 UTC