Peter and Mikael,

I think this is worth a crosspost with the bibo group.

I probably made what was a common misinterpretation of OWL  
DatatypeProperties in my previous post. They are not the same as rdf  
datatypes. The bibo example rdf in any of my past examples should have  
looked like

<my/foo> bibo:doi "info:doi/xxxxxx"^^xsd:anyURI

The OWL DatatypeProperty defines a restriction of rdfs:Datatype on the  
Literal value of a subject/predicate/Literal triple.

bibo:doi a owl:DatatypeProperty ;
     ...
     rdfs:subPropertyOf bibo:identifier ;
     rdfs:domain [  a owl:Class; owl:unionOf (bibo:Document  
bibo:Collection) ] ;
     rdfs:range rdfs:Literal .

However, there seems to be something very different between the bibo  
schema above and the example in the OWL spec, In this case, maybe bibo  
should be more explicit that the Literal actually have a stronger  
datatype?

http://www.w3.org/TR/owl-ref/#rdf-datatype

> <owl:DatatypeProperty rdf:about="#timeStamp">
>   <rdfs:domain rdf:resource="#Measurement"/>
>   <rdf:range rdf:resource="&xsd;dateTime"/>
> </owl:DatatypeProperty>
>
> <Measurement>
>   <timeStamp rdf:datatype="&xsd;dateTime">2003-01-24T09:00:08+01:00</ 
> timeStamp>
> </Measurement>

Seems to me the range in the bibo doi DatatypeProperty should be a  
more specific datatype than "Literal", otherwise, its not very  
meaningfull?

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#anyURI

bibo:doi a owl:DatatypeProperty ;
     ...
     rdfs:subPropertyOf bibo:identifier ;
     rdfs:domain [  a owl:Class; owl:unionOf (bibo:Document  
bibo:Collection) ] ;
     rdfs:range xsd:anyURI .

Likewise, In the above case, we may want to get into discussions about  
if URN, and/or other specific URI schemes should be considered  
"Syntaxes"? We know that info:hdl, info:doi, urn:, and urn:uuid are  
examples of URI that have more specific BNF than xsd:anyURI.

-Mark

On Sep 19, 2008, at 4:24 AM, Mikael Nilsson wrote:

> Pete,
>
> The pattern you're describing is interesting.
>
> I don't think the answer is given - it depends on what it really is  
> that
> varies between the different identifiers.
>
> My inclination would be to
>
> 1. Define sub-properties for each different PURPOSE of the identifier
> 2. Define a new datatype (SES) for each different SYNTAX
>
> Generally, the same syntax could potentially be used for different
> purposes.
>
> I don't find it "heavier" in any sense of the word to define a new
> syntax encoding scheme as compared to defining a new property. But I
> also don't really see the conflict - each new syntax SHOULD really  
> have
> its own SES, regardless of how that syntax is used as a property  
> value.
>
> /Mikael
>
>
>
>
> On fre, 2008-09-12 at 11:02 +0100, Pete Johnston wrote:
>> I'm trying to decide how best to model a requirement (which I think  
>> is
>> probably a reasonably common one - if not for the identifier case  
>> then
>> for some other property) and I'd welcome any advice/thoughts.
>>
>> The requirement is, for a specific resource type, to allow for the
>> provision of a number of identifiers, from an extensible list of  
>> types
>> of identifier e.g. I know now that for resources of type Foo,  there
>> exist fooInternationalIdNo and fooGlobalRegNo, but I need to allow  
>> for
>> the potential existence of fooGalacticRefNo and fooUniversalId in the
>> future.
>>
>> Ideally these would all have some mapping to URIs and there would  
>> be no
>> problem, but as it is right now, they are just literal strings.
>>
>> I can think of two possible approaches
>>
>> (i) Specify the use of the dc:identifier property (in DSP terms,
>> property list cosntraint 6.4.1 with one member) with a requirement to
>> provide a datatype/SES URI (a Literal value constraint with a Syntax
>> Encoding Scheme constraint (6.5.4)), and coin SES for
>> my:fooInternationalIdNo and my:fooGlobalRegNo (allowing for other  
>> SES in
>> the future)
>>
>> (ii) Specify a subproperty constraint (DSP 6.4.2) allowing any
>> subproperty of either dc:identifier or a my:fooIdentifier property  
>> (with
>> Literal range) and coin subproperties for my:fooInternationalIdNo and
>> my:fooGlobalRegNo (allowing for other subproperties in the future)
>>
>> I'm slightly more inclined to (ii) as
>>
>> (a) it seems to fit with approaches in other ontologies e.g. in the
>> Bibliographic Ontology [1] where new subproperties of dc:identifier  
>> are
>> created for various literal identifiers (though I think in that
>> particular case, at least some of them do have URI mappings)
>>
>> (b) if I choose to, it enables me to specify that the list should be
>> limited to fooIdentifiers rather than identifiers of any resource  
>> type
>>
>> (c) I have a tendency to think that defining new SES/datatypes is not
>> something to be taken lightly
>>
>> Would (ii) be a reasonable approach please?
>>
>> Thanks
>>
>> Pete
>>
>> [1] http://bibliontology.com/
>>
>> ---
>> Pete Johnston
>> Technical Researcher, Eduserv Foundation
>> [log in to unmask]
>> +44 (0)1225 474323
>> http://www.eduserv.org.uk/foundation/
>> http://efoundations.typepad.com/efoundations/
>>
> -- 
> <[log in to unmask]>
>
> Plus ça change, plus c'est la même chose