Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

E5 Mapping 'gcis:Image' and 'gcis:Figure' to external ontologies #77

Open
xgmachina opened this issue Jul 21, 2015 · 17 comments
Open

E5 Mapping 'gcis:Image' and 'gcis:Figure' to external ontologies #77

xgmachina opened this issue Jul 21, 2015 · 17 comments

Comments

@xgmachina
Copy link
Contributor

Make gcis:Image and gcis:Figure subclasses of fabio:Image and fabio:Figure, respectively. Also relate to the doco ontology if at all possible (http://www.essepuntato.it/lode/http://purl.org/spar/doco).

@justgo129
Copy link
Contributor

I forgot to add "assuming this is feasible from an ontological engineering perspective."

@congruili
Copy link
Contributor

How exactly would we want to relate gcis:Image and gcis:Figure to the doco ontology? What's the purpose of it?

@justgo129
Copy link
Contributor

To increase robustness of searches. e.g. someone searching for gcis:Figure in an extended SPARQL query

@congruili
Copy link
Contributor

doco:Figure -- A communication object comprising one or more graphics, drawings, images, or other visual representations.
Also make gcis:Figure subclass of doco:Figure?
There's no class related to "image" in the doco ontology though.

@justgo129
Copy link
Contributor

Thanks. Other ontologies then? Dbpedia? Fabio? Mainly, I'd just like to see further robustness for gcis:Image and gcis:Figure if at all possible to account for the fact that many users may not be searching under "gcis:Image" and "gcis:Figure" in order to locate these items.

@congruili
Copy link
Contributor

foaf has an image class, but no"figure".

http://xmlns.com/foaf/spec/#term_Image

@justgo129
Copy link
Contributor

It might just be best to just look at figures, then, assuming that our definition for figure matches others. Please feel free to suggest specific examples of potential compatibility for future discussion, given our immediate interest in additional SPARQL queries:

gcis:Figure a owl:Class ;
rdfs:label "Figure" ;
rdfs:comment "A graphical/visual item in a publication that normally is referred to by a number and that has a caption." ;
rdfs:subClassOf prov:Entity .

gcis:hasImage a owl:ObjectProperty ;
rdfs:label "Has Image" ;
rdfs:comment "The graphical component of a Figure." ;
rdfs:domain gcis:Figure, gcis:Image ;
rdfs:range gcis:Image ;
rdfs:subPropertyOf dcterms:hasPart .
(yes, I know the latter is a property but I need to update some other defns).

Image = panel of figure

@justgo129
Copy link
Contributor

@lic10 could you please inform as to the status of this effort? Thanks!

@congruili
Copy link
Contributor

Here is a summary:

dbpedia:Figure
http://dbpedia.org/page/Figure

doco:Figure -- A communication object comprising one or more graphics, drawings, images, or other visual representations.

foaf:Image
http://xmlns.com/foaf/spec/#term_Image

@justgo129
Copy link
Contributor

Thanks, @lic10. Let's either relate gcis:Figure to doco:Figure within the ontology or just conclude the turtle templates for figures with "a gcis:Figure, doco:Figure ." Which do you recommend? @rewolfe I think that doco:Figure would work with our definition of figure. Do you agree? Would every gcis:Figure be a doco:Figure?

<owl:Class rdf:about="&doco;Figure">
    <rdfs:label xml:lang="en">figure</rdfs:label>
    <rdfs:subClassOf rdf:resource="&deo;DiscourseElement"/>
    <rdfs:subClassOf>
        <owl:Class>
            <owl:unionOf rdf:parseType="Collection">
                <rdf:Description rdf:about="&pattern;Meta"/>
                <rdf:Description rdf:about="&pattern;Milestone"/>
            </owl:unionOf>
        </owl:Class>
    </rdfs:subClassOf>
    <rdfs:comment xml:lang="en">A communication object comprising one or more graphics, drawings, images, or other visual representations..</rdfs:comment>
</owl:Class>

gcis:Figure a owl:Class ;
rdfs:label "Figure" ;
rdfs:comment "A graphical/visual item in a publication that normally is referred to by a number and that has a caption." ;
rdfs:subClassOf prov:Entity .

With regard to image, I am not a big fan of integrating with foaf:Image as that class uses "Image" in the definition. Is a gcis:Image compatible with a fabio:Image or would fabio:Image include a caption, title, etc.?

<owl:Class rdf:about="&spar;fabio/Image">
    <rdfs:label xml:lang="en">image</rdfs:label>
    <rdfs:subClassOf rdf:resource="&spar;fabio/Work"/>
    <rdfs:comment xml:lang="en">A visual representation other than text, including all types of moving image and still image.</rdfs:comment>
</owl:Class>

gcis:Image a owl:Class ;
rdfs:label "Image" ;
rdfs:comment "A copy of something in the form of a visual representation. Examples include images and photographs of physical objects, paintings, prints, drawings, other images and graphics, animations and moving pictures, film, diagrams, maps, musical notation, etc." ;
rdfs:subClassOf bibo:Image , gcis:Publication , prov:Entity .

@rewolfe
Copy link
Member

rewolfe commented Aug 26, 2015

+1 - Yes, these definitions are compatible with the GCIS definitions of
Figure and Image. Note that in GCIS, a Figure may contain one or more
Images. This means that an Image may have a Caption, but indirectly by
creating a Figure (with a Caption) that contains the Image.

On Tue, Aug 25, 2015 at 9:47 PM, justgo129 notifications@github.com wrote:

Thanks, @lic10 https://github.com/lic10. Let's either relate
gcis:Figure to doco:Figure within the ontology or just conclude the turtle
templates for figures with "a gcis:Figure, doco:Figure ." Which do you
recommend? @rewolfe https://github.com/rewolfe I think that doco:Figure
would work with our definition of figure:
gcis:Figure a owl:Class ;
rdfs:label "Figure" ;
rdfs:comment "A graphical/visual item in a publication that normally is
referred to by a number and that has a caption." ;
rdfs:subClassOf prov:Entity .
do you agree? Would every gcis:Figure be a doco:Figure?

With regard to image, I am not a big fan of integrating with foaf:Image
because it uses "Image" in the definition. Is a gcis:Image compatible with
a fabio:Image or does fabio:Image include a caption, title, etc.?

<owl:Class rdf:about="∥fabio/Image">
<rdfs:label xml:lang="en">image/rdfs:label
<rdfs:subClassOf rdf:resource="∥fabio/Work"/>
<rdfs:comment xml:lang="en">A visual representation other than text, including all types of moving image and still image./rdfs:comment
/owl:Class

gcis:Image a owl:Class ;
rdfs:label "Image" ;
rdfs:comment "A copy of something in the form of a visual representation.
Examples include images and photographs of physical objects, paintings,
prints, drawings, other images and graphics, animations and moving
pictures, film, diagrams, maps, musical notation, etc." ;
rdfs:subClassOf bibo:Image , gcis:Publication , prov:Entity .


Reply to this email directly or view it on GitHub
#77 (comment)
.

Robert Wolfe, NASA GSFC @ USGCRP, o: 202-419-3470, m: 301-257-6966

@justgo129
Copy link
Contributor

Excellent. @lic10 please advise as to whether we should 1) integrate gcis:Figure with doco:Figure and gcis:Image with fabio:Image within the owl file, or 2) we should leave the owl file as is and conclude the templates with:
a gcis:Figure, doco:Figure .
a gcis:Image, fabio:Image .

I will then prepare the pull request.

@xgmachina
Copy link
Contributor Author

@justgo129 I prefer option 2) in your comment. To add the assertions at the instance level.

@justgo129
Copy link
Contributor

Excellent. Please feel free to prepare the pull request.

@bduggan
Copy link
Contributor

bduggan commented Aug 27, 2015

Once inferencing is enabled, it would be consistent with our handling of prov:Entity to instead put these into the ontology.

@justgo129
Copy link
Contributor

The pull request for option 2 is available at: USGCRP/gcis#237.
Once we enable inferencing, we can revise the OWL document accordingly.

@justgo129
Copy link
Contributor

Addressed with USGCRP/gcis#237 but will keep open for review after inferencing is enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants