---------------------------------------------------------------------- 2007-02-26 From: Ivan Herman Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK As has been told many times, the usage of DC is today so widespread that the Library community is only a part of (and maybe even a fraction of) the user community. According to some estimates, after the core SW namespaces (rdf, rdfs, owl), the DC namespace is the largest single namespace used on the Semantic Web. We should not forget that. I think our options here are: 1. the ranges are *not* restricted. Ie, one could use datatypes directly, or more complex solutions 2. the ranges are defined with the help of OWL's union facility. This union should refer to the xsd datatypes that we want for a specific predicate, plus more complex classes that are required/used by the library community. Frankly, I do not see any other solution. The current approach, in my view, penalizes a large user community... ---------------------------------------------------------------------- Date: Mon, 26 Feb 2007 10:43:52 +0100 From: Mikael Nilsson Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK On m=C3=A5n, 2007-02-26 at 09:25 +0100, Ivan Herman wrote: > 1. the ranges are *not* restricted. Ie, one could use datatypes > directly, or more complex solutions > 2. the ranges are defined with the help of OWL's union facility. This > union should refer to the xsd datatypes that we want for a specific > predicate, plus more complex classes that are required/used by the > library community. Actually, I think you might have missed the precise details of what we are proposing... The current set of 15 properties in the http://purl.org/dc/elements/1.1/ namespace (traditionally dc:) will *not* be given ranges and domains. Instead, these 15 properties will be copied to the http://purl.org/dc/terms/ namespace (traditionally dcterms: or dcq:). These "new" terms will be given domains and ranges, and will be made subproperties of the dc: terms. The existing terms in the dcterms: namespace will also be affected, but their use is far less widespread. So, any use of the old dc: terms will fall under your option 1. above, i.e. no restriction. At the same time, DCMI will recommend (but not require) the use of the newer terms. In the long term, that will hopefully mean than more and more uses of Dublin Core will make use of the semantically richer terms in the dcterms: namespace (as well as unifying all terms in a single namespace). > Frankly, I do not see any other solution. The current approach, in my > view, penalizes a large user community... The DCMI community has struggled with this exact issue for a few years now. The hope is that this compromise leads to the best of both worlds. Of course, feedback on that is more than welcome! ---------------------------------------------------------------------- Date: Mon, 26 Feb 2007 07:53:34 -0500 From: Bruce D'Arcus Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK On Feb 26, 2007, at 4:43 AM, Mikael Nilsson wrote: >> Frankly, I do not see any other solution. The current approach, in my >> view, penalizes a large user community... > > The DCMI community has struggled with this exact issue for a few years > now. The hope is that this compromise leads to the best of both worlds. > Of course, feedback on that is more than welcome! But WRT to Ivan's suggestions here (either to not limit these particular properties, or to use the OWL unionOf option to offer a choice), where is the compromise? As you say above: > In the long term, that will hopefully mean than more and more uses of > Dublin Core will make use of the semantically richer terms in the > dcterms: namespace (as well as unifying all terms in a single > namespace). This makes a whole lot of sense for most of the properties, but I actually think it would be a bad thing to see everyone modeling titles and dates and descriptions as full resources. E.g. you seem to characterize this (richer description) as best practice, but I don't think it is in all cases. Moreover, the wide practice of modeling titles and dates as resources will never happen practically because most people (developers and non-developers alike) would consider it overkill, which then leads to an even bigger problem that I thought this effort was designed to overcome (inconsistency). Just as a practical matter, I'm working with the OpenDocument group at OASIS on adding RDF support to the format, and on related work on citations. I was excited to see this effort to clarify DC because we can just point developers to your documentation and be content that they will know what to do. But I would find it really awkward to tell developers "well, OK, use dcterms namespace for most properties, but if you want to treat titles as literals, better to use dc:title." ---------------------------------------------------------------------- Date: Mon, 26 Feb 2007 19:45:15 +0100 From: Mikael Nilsson Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK > Moreover, the wide practice of modeling titles and dates as resources > will never happen practically because most people (developers and > non-developers alike) would consider it overkill, which then leads to > an even bigger problem that I thought this effort was designed to > overcome (inconsistency). Two things are happening in parallel here, so please make sure we distinguish them: 1. In general, the assignment of domains and ranges to a number of terms in the dcterms: namespace, including the replicated dc: terms. 2. Specifically, assignment to ranges and domains to specific properties which might or might not be reasonable. So, I would like to know if we are discussion 1) the principle of assigning domains and ranges AT ALL, or 2) the particular domains and ranges of certain properties. I *think* you mean 2). If that is correct, we need to enumerate the problematic properties, and find a solution that does what we want and need. Note, I'm now leaving the dc: namespace and *only* talking about the dcterms: namespace A) dcterms:title and description. Looking at the draft, they have been given a range of "rdfs:Resource". That is, literals are allowed. This, naturally, has to do with the fact that a string is actually a useful title/description. So you should not have to worry there. B) dcterms:date. The range of this property is Period. Now, as it stands, xsd:date is not a subClassOf Period. However, this has been put forward as a possibility. Now, please look at the proposed DC in RDF specification, section 5: http://dublincore.org/documents/dc-rdf/#sect-5 and in particular the paragraph "RDF shorthand for RDF plain literals and RDF typed literals". Essentially, this says that if your datatype is a subclass of the range of the property, the DCAM allows you to use the typed string as direct object in an RDF statement involving the property. Thus, IF xsd:date were made subClassOf dcterms:Period, you could do dcterms:modified "2007-01-01"^^xsd:date etc. So, we need to gather all problematic cases, one by one, and take a stand on how to address them. > Just as a practical matter, I'm working with the OpenDocument group at > OASIS on adding RDF support to the format, and on related work on > citations. I was excited to see this effort to clarify DC because we > can just point developers to your documentation and be content that > they will know what to do. But I would find it really awkward to tell > developers "well, OK, use dcterms namespace for most properties, but if > you want to treat titles as literals, better to use dc:title." So, this particular case is NOT a valid criticism.... :-) ---------------------------------------------------------------------- Date: Tue, 27 Feb 2007 13:26:06 +0100 From: Ivan Herman Organization: World Wide Web Consortium (W3C) Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK Mikael Nilsson wrote: [snip] > Note, I'm now leaving the dc: namespace and *only* talking about > the dcterms: namespace Agreed. That was my understanding, too > A) dcterms:title and description. Looking at the draft, they have been > given a range of "rdfs:Resource". That is, literals are allowed. This, > naturally, has to do with the fact that a string is actually a useful > title/description. So you should not have to worry there. > Yep. Although the question is whether an explicit range restriction for a Literal is not a better solution. See below... > B) dcterms:date. The range of this property is Period. Now, as it > stands, xsd:date is not a subClassOf Period. However, this has been put > forward as a possibility. > [snip] > > Thus, IF xsd:date were made subClassOf dcterms:Period, you could do > > dcterms:modified "2007-01-01"^^xsd:date > That is *technically* correct. What I mean is that it is certainly correct in terms of the RDFS syntax and semantics. However, I must admit I find it counter-intuitive. And I also find a potential pitfall here. Indeed: I know that DC has not considered using OWL at the moment. However, it might be a good idea to slightly think a bit ahead: what if either DC or some other organization would like to use the DC terms in an OWL, more exactly in an OWL-DL setting? This may sound far fetched at first glance, but again may not be that impossible. After all, as I remarked already at some point, the Dublin Core terms have become ubiquitous on the Semantic Web (you are the victims of your own success:-), and if people want to build up more formal ontologies, they may well want to include DC terms. However... the solution you propose would *not* be correct OWL DL, because OWL DL does not allow redefining the semantics of the 'core' RDF terms (and this is what happens with your approach!). Actually, my previous solution of using owl:unionOf does not work either, because OWL DL requires a separation of datatype and object properties. But maybe this is the case, actually, where the rigour of Description Logic may help in cleaning up the terms... What if the new dcterm namespace includes some of the properties in duplicate? What I mean, what about saying: dcterm has a dcterm:modified and dcterm:modifiedPeriod properties? One could then say dcterm:modified rdf:type rdfs:Property; rdfs:range xsd:date. dcterm:modifiedPeriod rdf:type rdfs:Property; rdfs:range dcterm:Period. If one wanted to turn that into OWL-DL aware definitions, it becomes simple; one just adds dcterm:modified rdf:type owl:DatatypeProperty. dcterm:modifiedPeriod rdf:type owl:ObjectProperty. Thinking about this again, I have the impression that this leads to a much cleaner modelling. My estimate is (I do not have the numbers at hand, though) that a vast majority of users would be perfectly content with the usage of dcterm:modified with the extra bonus of a possible type checking on the datatype (which is a big plus compared to dc:modified); this could include the OpenDocument users and many others. Digital Library users that you were referring to may have to use more complex terms; they could then use dcterm:modifiedPeriod which would satisfy their needs. Is that an impossible avenue to consider? Just food for thoughts... ---------------------------------------------------------------------- Date: Tue, 27 Feb 2007 16:45:24 +0100 From: Mikael Nilsson Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK On tis, 2007-02-27 at 13:26 +0100, Ivan Herman wrote: > However... the solution you propose would *not* be correct OWL DL, > because OWL DL does not allow redefining the semantics of the 'core' RDF > terms (and this is what happens with your approach!). Can you clarify this last statement? Where do we redefine the semantics of the core RDF terms? > Actually, my > previous solution of using owl:unionOf does not work either, because OWL > DL requires a separation of datatype and object properties. Right, that *is* a problem, I can see that too. > If one wanted to turn that into OWL-DL aware definitions, it becomes > simple; one just adds > > dcterm:modified rdf:type owl:DatatypeProperty. > dcterm:modifiedPeriod rdf:type owl:ObjectProperty. I can see why you would want that, but I am unsure whether that would actually lead to increased interoperability. I think the solution is to be found elsewhere. Maybe the "shortcut" notion in the DC-RDF document is wrong, and we should rely on literal/datatype ranges for some properties? I don't knkow. > Is that an impossible avenue to consider? I think a doubling of the number of terms for technical reasons is rather impossible, yes... :-) ---------------------------------------------------------------------- Date: Tue, 27 Feb 2007 20:27:46 +0100 From: Ivan Herman Organization: World Wide Web Consortium (W3C) Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK > Can you clarify this last statement? Where do we redefine the semantics > of the core RDF terms? I may not have used the right terminology here, sorry. In OWL DL, datatypes are strictly separated from OWL classes. The xd:data subClassOf YourOwnClass violates that separation. Put it another way, you cannot express such statement in traditional Description Logic, where datatypes are strictly 'outside' the core subject of discourse. >>If one wanted to turn that into OWL-DL aware definitions, it becomes >>simple; one just adds >> >>dcterm:modified rdf:type owl:DatatypeProperty. >>dcterm:modifiedPeriod rdf:type owl:ObjectProperty. > > I can see why you would want that, but I am unsure whether that would > actually lead to increased interoperability. I think the solution is to > be found elsewhere. I am happy if there is one...:-) But I do not see any at the moment. > Maybe the "shortcut" notion in the DC-RDF document is wrong, and we > should rely on literal/datatype ranges for some properties? I don't > knkow. I am not sure what you mean here. Do you mean that in some cases you would define extra XML Schema datatypes for ranges? That may work, but somehow I am not sure it would work for all of them. >>Is that an impossible avenue to consider? > > I think a doubling of the number of terms for technical reasons is > rather impossible, yes... :-) > Why? I am just curious... We may not have to duplicate *all* predicates (I have not checked, though) ---------------------------------------------------------------------- Date: Thu, 1 Mar 2007 08:03:39 -0000 From: Pete Johnston Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK Mikael said: > I think a doubling of the number of terms for technical reasons is > rather impossible, yes... :-) I dunno... it would introduce a level of complexity in how DCMI presents/documents stuff, and we'll have to explain things very carefully to the Usage Board, but I'm starting to wonder whether it may not in fact be the "cleanest" (and as Ivan says, most "future-proof") solution. We could probably handle the partitioning of terms at the "namespace" level e.g. dcterms:modified v someotherdc:modified Are there any implications for subproperty assertions though? e.g. Could we continue to say (directly or through a chain of inferences) that an object property and a datatype property are both subproperties of a DCMES property (with no range/domain)? Or would that result in breaking the OWL-DL constraint too? ---------------------------------------------------------------------- Date: Thu, 1 Mar 2007 09:36:20 +0100 From: Ivan Herman Organization: World Wide Web Consortium (W3C) Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK Pete Johnston wrote: > e.g. Could we continue to say (directly or through a > chain of inferences) that an object property and a datatype > property are both subproperties of a DCMES property (with no > range/domain)? Or would that result in breaking the OWL-DL > constraint too? I am not sure. I am not a foolproof Description Logic expert, to be frank, but my first reaction is 'probably not' (I mean: it would probably break DL). The best way is to use an online checker. I myself used http://phoebus.cs.man.ac.uk:9999/OWL/Validator which will yell at you if you create a problem. I used that to check some of my previous statements, to avoid making a complete fool of myself:-) ---------------------------------------------------------------------- Date: Thu, 1 Mar 2007 08:37:57 -0000 From: Pete Johnston Subject: Re: Commain on the domain range draft To: DC-ARCHITECTURE@JISCMAIL.AC.UK Or to put it another way, if OWL DL (sub)classes all properties as either DatatypeProperty or ObjectProperty, then we have to apply that approach across the board, including the DCMES, which kind of undercuts the current strategy of not changing the range of those properties? Maybe that strategy needs to be undercut - I'm just trying to get clear all the implications of the suggestion. ---------------------------------------------------------------------- Date: Tue, 13 Feb 2007 09:47:22 +0000 From: Ivan Herman Subject: Comment on DCAM To: DC-ARCHITECTURE@JISCMAIL.AC.UK Third mail from a RDF geek... I understand there is a subtle complication between the DC abstract model and RDF for properties. In DC-Text syntax, one can say: DescriptionSet ( Description ( ResourceURI ( ) Statement ( PropertyURI ( dc:publisher ) ValueURI ( ) ValueString ( "Dublin Core Metadata Initiative" ) ) ) ie, a property *may* have a string value *and* a URI at the same time, so to say. The way I would translate that into RDF is something like dc:publisher [ # maybe some type information would be in order here rdf:value "Dublin Core Metadata Initiative"; dc:somepropertyhere . ]. The caveat is when one wants to define the range of the dc:publisher. Indeed, this should be defined as a union, namely a union of a literal *a nd* some other type that is used above. Alternatively, the range has to stay a general resource, ie, nothing is really said about the range. Being a bit of an outsider to the core DC discussions, this is all fine with me, but it should be explicitly said and documented... (dc:publisher may be a wrong example here; it seems that the new document for ranges defines its range to be an Agent, ie, no direct Literal is allowed anyway. But the issue may come up for other properties...) ---------------------------------------------------------------------- Date: Wed, 21 Feb 2007 16:07:48 -0000 From: Pete Johnston Subject: Re: Comment on DCAM To: DC-ARCHITECTURE@JISCMAIL.AC.UK Ivan said: > I read the document from an RDF point of view, and my comment > is probably for clarification only (but it may be worth > either adding this to the document or having a separate, > explanatory document). > > - The document defines a rich representation. I tried to > translate a rich representation into RDF, and I am not sure > it is correct. What I came up with as an example (using > Turtle syntax) is: > > dc:blabla [ > dcterms:format [ > rdf:type ex:MediaType; > dc:label "image/jpeg"; > ] > rdf:value "base64 encoded bytes of the image". > ]. > > ie, the property using a rich representation refers to a > blank node that includes a reference to a media type and the > value. Yes, that is pretty much how I envisaged the rich representation notion being represented using RDF. Actually, given that (according to the DCAM) a single statement may provide multiple rich representations for a single value, I think there may be an additional node and arc involved. So if, say, I want to say that a book was authored by some entity represented by a JPEG and by a GIF, then I think in RDF, that would look something like (gulp): _:mybook a ex:Book ; dcterms:creator [ rdfs:seeAlso [ dcterms:format [ rdf:type ex:MediaType ; rdfs:label "image/jpeg" ; ] ; rdf:value "base64 encoded bytes"^^xsd:base64Binary ] ; rdfs:seeAlso [ dcterms:format [ rdf:type ex:MediaType ; rdfs:label "image/png" ; ] ; rdf:value "base64 encoded bytes"^^xsd:base64Binary ] ] . (Probably with some question marks over whether we use rdfs:seeAlso/rdf:value or some other properties?) > The ex:MediaType is defined, in [1], as a class, hence > the extra blank node. It is also not clear how one defined a > particular media type.. Are their URIs for the IANA registered MIME types? I found http://www.w3.org/2001/tag/2002/01-uriMediaType-9 expressing the desirability of having some URIs, but I'm not sure whether any were assigned/are in widespread use. ---------------------------------------------------------------------- Date: Mon, 26 Feb 2007 09:21:37 +0100 From: Ivan Herman Organization: World Wide Web Consortium (W3C) Subject: Re: Comment on DCAM To: DC-ARCHITECTURE@JISCMAIL.AC.UK Pete Johnston wrote: > (Probably with some question marks over whether we use > rdfs:seeAlso/rdf:value or some other properties?) I think to re-use as much as possible existing properties is a good thing, so... >>The ex:MediaType is defined, in [1], as a class, hence >>the extra blank node. It is also not clear how one defined a >>particular media type.. > > Are their URIs for the IANA registered MIME types? > > I found http://www.w3.org/2001/tag/2002/01-uriMediaType-9 expressing the > desirability of having some URIs, but I'm not sure whether any were > assigned/are in widespread use. Unfortunately, I do not know more. Maybe it is a question you may want to ask on the SW Interest Group, somebody may know about one... It may well be that DCI will have to define those. Having a set of URI-s for Media types would be a great plus for the community... ---------------------------------------------------------------------- Date: Thu, 22 Feb 2007 20:47:23 +0100 From: Mikael Nilsson Subject: [DCAM Piblic Comment] DCAM vs RDF and ranges (was:Comment on DCAM) To: DC-ARCHITECTURE@JISCMAIL.AC.UK > dc:publisher [ > # maybe some type information would be in order here > rdf:value "Dublin Core Metadata Initiative"; > dc:somepropertyhere . > ]. Well, except the Value URI will be the uri of the object node (object of the dc:publisher property) > for ranges defines its range to be an Agent, ie, no direct Literal is > allowed anyway. But the issue may come up for other properties...) The intention of the new domains and ranges indeed tries to address this very problem - DCMI is moving away from "Literal or resource" to a more precise range, relying on rdf:value to provide value strings. So, this should be read together with the domains/ranges document, AND, http://dublincore.org/documents/dc-rdf/ which is still not fully up-to-date with these DCAM modifications, but gives you an idea of the direction. In short, we want DC to fully interoperate in an RDF world, while still being just as useful in other contexts (OAI etc), ---------------------------------------------------------------------- Date: Mon, 26 Feb 2007 11:11:03 +0100 From: Ivan Herman Organization: World Wide Web Consortium (W3C) Subject: Re: [DCAM Piblic Comment] DCAM vs RDF and ranges To: DC-ARCHITECTURE@JISCMAIL.AC.UK > So, this should be read together with the domains/ranges document, AND, > > http://dublincore.org/documents/dc-rdf/ Thanks for this pointer. I looked through the examples, so let me ask the following. I understand that you can write or it can become more complicated, like: Biology EA32 But does it mean that you will no longer be allowed to use: EA32 Or, as a really simple case: something The problem I have is that *most* (non-librarian) users of DC will still use the pure and simple literal. How will you accomodate with that? Maybe you should have dc:subject and dc:complexSubject when necessary. For other predicates, some sort of an owl:unionOf might be hand to define precise range. I am not sure. But what I know that for *lot* of people the combination with the value String is a little bit too complicated. [Actually, I have the impression that what you are fighing with here is the fact that one cannot use a literal in a subject position in RDF. Some would like to remove this restriction, but, well, when and how this issue will be reopened nobody knows...] ---------------------------------------------------------------------- Date: Mon, 26 Feb 2007 11:42:38 +0100 From: Mikael Nilsson Subject: Re: [DCAM Piblic Comment] DCAM vs RDF and ranges To: DC-ARCHITECTURE@JISCMAIL.AC.UK On m=C3=A5n, 2007-02-26 at 11:11 +0100, Ivan Herman wrote: > Hi Mikael, > Thanks for this pointer. I looked through the examples, so let me ask > the following. I understand that you can write > > > > right. > > or it can become more complicated, like: > > > > > Biology > rdf:datatype="http://example.org/taxonomy/SubjectEncoding"> > EA32 > > > > Yes, except dcrdf:valueString will probably become just rdf:value in the next draft. > But does it mean that you will no longer be allowed to use: > > > rdf:datatype="http://example.org/taxonomy/SubjectEncoding">EA32 > Again, for the dc: properties, you will be able to do more or less what you want. There will be a new property, called dcterms:subject. Now, this new property won't have a restricted range, as more or less anything can be used as the "subject" of a resource, so it's actually open for all kind of uses too. > Or, as a really simple case: > > > something > > > The problem I have is that *most* (non-librarian) users of DC will still > use the pure and simple literal. How will you accomodate with that? Use the dc: terms in all such cases, and you don't have to change one thing... > Maybe you should have dc:subject and dc:complexSubject when necessary. We will have dc:subject and dcterms:subject. > For other predicates, some sort of an owl:unionOf might be hand to > define precise range. I am not sure. But what I know that for *lot* of > people the combination with the value String is a little bit too > complicated. > > [Actually, I have the impression that what you are fighing with here is > the fact that one cannot use a literal in a subject position in RDF. > Some would like to remove this restriction, but, well, when and how this > issue will be reopened nobody knows...] Well, partly that, but mostly the fact that, for example, the creator of a resource is never a string, but a person, and we want that reflected in the model. The issue is that dc: properties aren't very useful for many RDF uses, simply because one does not know whether to expect a literal or non-literal as value of a given property. Please have a further look at http://dublincore.org/documents/dc-rdf-notes/ that accompanied the dc-rdf draft you read above. ---------------------------------------------------------------------- From: Guus Schreiber To: Alistair Miles CC: SWD WG , SKOS Alistair Miles wrote: > I tried to illustrate some of the issues relating to SKOS and OWL DL > compatibility, see: > > http://www.w3.org/2006/07/SWD/wiki/SkosDesign/OwlCompatibility?action=recall&rev=7 On my todo list is still to write a message to owl-dev entitled something like "forcing a distinction between datatype and object properties leads to ontological overcommitments". The findings of Alistair are a pattern I've seen now a number of times. In our digital heritage projects we have the same problem, e.g. when specializing Dublin Core [1]. For Dublin-Core like properties one often cannot commit to a specific range, not even individual or literal. The pattern we use is the following: - specify properties with rdf:Property, indicating only the range in unequivocal cases - when you know for subparts of the collection which ranges (e.g. vocabulary parts) you want to use, write local range restriction (using owl:Restriction) in a separate local scheme. This approach allows others to use the property with another range.