two properties representing an object having a dcoid, remove one of them

[mrpatrickwest]

Both are being used. Are they duplicates? Or do they mean something completely different.

Also, dco:dcoId is an annotation property as well as a functional property and a datatype property. Should not be an annotation property.

dco:dcoId
      a       owl:FunctionalProperty , owl:AnnotationProperty , owl:DatatypeProperty ;
      rdfs:domain dco:Object ;
      rdfs:label "DCO ID"@en-US ;
      rdfs:range xsd:anyURI ;
      rdfs:subPropertyOf owl:topDataProperty , dco:dcoId .

dco:hasDcoId
      a       owl:FunctionalProperty , owl:InverseFunctionalProperty , owl:ObjectProperty ;
      rdfs:domain dco:Object ;
      rdfs:label "DCO ID"@en-US ;
      rdfs:range dco:DCOID ;
      owl:inverseOf dco:dcoIdFor .

[zednis]

Some thoughts from looking at an example from the instance data.

example:

<http://dx.deepcarbon.net/11121/1220-7065-2371-5711-CC>
      a       dco:DCOID , owl:Thing ;
      rdfs:label "11121/1220-7065-2371-5711-CC" ;
      dco:dcoIdFor <http://info.deepcarbon.net/individual/n12622> .

I noticed two things:

1) This DCOID instance did not use dco:dcoId. We may want to some some follow-up to see how consistent our DCOID instances are re: dco:dcoId vs rdfs:label

2) dco:hasDcoId doesn't show up when I get the RDF for the publication individual (see https://info.deepcarbon.net/vivo/individual/n12622/n12622.ttl), but is available to queries. Is it possible it is being inferred and is in a graph that is not used to generate the RDF published by VIVO?

[zednis]

..additional thoughts

We greatly simplify our model if we drop the dco:DCOID class and dco:hasDcoId and dco:dcoIdFor. We don't appear to be using the DCOID instances for any description beyond the literal value of the DCO ID, so I don't think we have a requirement to create a separate resource for each DCO ID.

I think it makes sense to retain dco:dcoId as a functional datatype property (remove annotation property type) with a domain of dco:Object and remove the dco:DCOID class and dco:hasDcoId and dco:dcoIdFor properties.

[mrpatrickwest]

There was an issue with making the dcoid property a datatype property, but I can't remember what that was. We need to ask @olyerickson and Marshall (who does not have an account?)

[zednis]

Marshall is @xgmachina

[olyerickson]

I'm looking through our email threads on this (from two years ago) and I found this in an email from Patrick:

"...In a purely ontological sense, the fact that we state that a dco:dcoid is a datatype property with domain dco:Object is enough. We don't have to have place holders in classes for this property. Whenever we assign a dcoid property to an entity, it automatically becomes a dco:Object, it's inferred. And we can search for a foaf:Person who has a dcoid, and that person is a dco person. We don't need that placeholder class.

"But, because VIVO/VITRO needs to be able to generate the forms, and the display, we need to have that placeholder..."

So I'm wondering if there was some issue with how DCO-IDs are presented --- perhaps giving them live links?

Remember that DOI is just a stupid data property, and we've never been able to live link DOI values (although we've thought it SHOULD be linked since the beginning)

John

On Tue, Aug 11, 2015 at 2:03 AM, Stephan Zednik notifications@github.com wrote:

Marshall is @xgmachina https://github.com/xgmachina

— Reply to this email directly or view it on GitHub https://github.com/tetherless-world/dco-ontology/issues/29#issuecomment-129718371 .

John S. Erickson, Ph.D. Director of Operations, The Rensselaer IDEA Deputy Director, Web Science Research Center (RPI) http://tw.rpi.edu olyerickson@gmail.com Twitter & Skype: olyerickson

[mrpatrickwest]

There are individuals that have both a hasDcoId and dcoId, and they are the same. There is no code that uses dco:dcoId. We always use dco:hasDcoId. There are 459 individuals that have a dco:dcoId but no dco:hasDcoId but they are all either unresolvable (go to deepcarbon.net/vivo instead of info.deepcarbon.net) or are used by bogus objects (test objects, broken objects, etc... very few of these, about a dozen).

First order of business is to eliminate dco:dcoId and remove any triples that contain it.

Then we can talk about dco:hasDcoId having a range of URI instead of an object. Should be like a DOI. Should be a literal and should be clickable. Perhaps this just means having a custom display for the property? Or finding in the code where it is displayed (we know in the code where the DOI is displayed, can we do the same thing)

[zednis]

Why remove dco:dcoId if the next order of business would be to possibly make dco:hasDcoId a functional equivalent?

If there is no code using dco:dcoId and it is not causing confusion anywhere in the interface I say we should leave it be till we have settled on a long-term resolution.

[mrpatrickwest]

Because those triples are dead weight. They aren't needed. So why not get rid of them so we don't have to worry about them. Makes for a cleaner knowledge store. Then when we decide what to do with dco:dcoId and dco:hasDcoId we can make a nice clean transition from hasDcoId to the other.

Same reason I'm getting rid of 15,000+ dco-id from the handle system that don't point to anything. It's cleaner that way and we can start anew.

[zednis]

I am suggesting we remove the property once we decide on a direction. Rather than remove dco:dcoId now and then have to convert all of dco:hasDcoId (sigh) into the exact same thing afterwards.