http://ontologydesignpatterns.org/api.php?action=feedcontributions&feedformat=atom&user=MariaPoveda 2026-04-15T20:50:36Z User contributions MediaWiki 1.25.6 http://ontologydesignpatterns.org/index.php?title=Reviews:MariaPoveda_about_TransportPattern&diff=11662 2013-08-06T07:48:33Z

<p>MariaPoveda: New page: {{Content OP Proposal Review Template |CreationDate=2013/8/6 |SubmittedBy=MariaPoveda |ContentOPUnderReview=TransportPattern |RevisionID=11661 |Score=0 - needs major revision |ReviewSummar...</p> <hr /> <div>{{Content OP Proposal Review Template<br /> |CreationDate=2013/8/6<br /> |SubmittedBy=MariaPoveda<br /> |ContentOPUnderReview=TransportPattern<br /> |RevisionID=11661<br /> |Score=0 - needs major revision<br /> |ReviewSummary=The goal of this pattern is modelling the movement of mass or energy from one place to another. Two competency questions are presented however the pattern does not seem to represent the information needed for answering them. Also, several fields are missing (e.g. scenarios, examples, related CPs)<br /> |ReviewConfidence=High confidence in ontology patterns and low confidence in the given domain.<br /> |ReviewProblems=My main problems about this pattern are:<br /> <br /> 1) The solution proposed is that general that needs a lot of effort to extend and specialize it so that the proposed competency questions could be answered.<br /> <br /> 2) The authors do not reuse or mention the already existing pattern &quot;Move&quot;<br /> |ReviewRelevance=Fair<br /> |ReviewBestPractice=Low<br /> |ReviewReusability=Fair<br /> |ReviewRelations=part-of, Move<br /> |ReviewUnderstandability=The pattern is not described in detail in the wiki page, it is difficult to understand it without the corresponding paper.<br /> |ReviewClearProblem=Good<br /> |ReviewClearRelevance=Fair<br /> |ReviewFigures=There is no diagram nor illustration.<br /> |ReviewMissing=Diagram<br /> Scenarios<br /> Web references<br /> Examples<br /> Related CPs<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:LicenseLinkedDataResources&diff=11618 2013-07-19T10:44:43Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=licenselinkeddataresources.png<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=VictorRodriguezDoncel, MariCarmenSuarezFigueroa, AsuncionGomezPerez, MariaPoveda, <br /> |Name=LicenseLinkedDataResources<br /> |Intent=To provide a pattern for expressing rights on Linked Data Resources, understood as RDF triples, datasets or mappings.<br /> These rights include intellectual property rights, database rights and the right of access, which can be limited by personal data protection laws and others.<br /> Rights expressions may assert, waive and license the rights, either conditionally or inconditionally, either to the public or to agents in particular.<br /> |Domain=Linked Data, Lincense<br /> |ContentODPDescription=-Adhere to the underlying structure present in other Rights Expression Languages<br /> <br /> -Be able to represent existing known licenses (i.e. Creative Commons licenses etc.)<br /> <br /> -Support database rights: extraction and re-utilization<br /> <br /> -Support privacy law (personal data handling) and the right to access<br /> <br /> -Support the intellectual property law rights: reproduction, distribution, transformation<br /> <br /> -Support these right declarations: Unconditionally waiving rights, Restating that some rights are reserved, Licensing rights subject to conditions<br /> <br /> -Supporting existing licensing practices for RDF resources<br /> <br /> -Supporting these business models: Open data business models, Non open data business models, Hybrid models.<br /> |ReusableOWLBuildingBlock=http://purl.oclc.org/NET/lldr/ns#<br /> |Consequences=A more precise attribution of rights expression to Linked Data<br /> |Scenario=Declaring rights on both Linked Open Data and Linked Closed Data<br /> |SpecializationOf=http://ontologydesignpatterns.org/wiki/Submissions:N-Ary_Relation_Pattern_(OWL_2)<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=http://vocab.deri.ie/void#<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://xmlns.com/foaf/0.1/<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://creativecommons.org/ns#<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://purl.org/dc/terms/<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://purl.org/dc/elements/1.1/<br /> }}<br /> {{Additional information header}}<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2013<br /> }}<br /> {{Submission to event}}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:LicenseLinkedDataResources&diff=11617 2013-07-19T10:41:14Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=licenselinkeddataresources.png<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=VictorRodriguezDoncel<br /> |Name=LicenseLinkedDataResources<br /> |Intent=To provide a pattern for expressing rights on Linked Data Resources, understood as RDF triples, datasets or mappings.<br /> These rights include intellectual property rights, database rights and the right of access, which can be limited by personal data protection laws and others.<br /> Rights expressions may assert, waive and license the rights, either conditionally or inconditionally, either to the public or to agents in particular.<br /> |Domain=Linked Data<br /> |ContentODPDescription=-Adhere to the underlying structure present in other Rights Expression Languages<br /> <br /> -Be able to represent existing known licenses (i.e. Creative Commons licenses etc.)<br /> <br /> -Support database rights: extraction and re-utilization<br /> <br /> -Support privacy law (personal data handling) and the right to access<br /> <br /> -Support the intellectual property law rights: reproduction, distribution, transformation<br /> <br /> -Support these right declarations: Unconditionally waiving rights, Restating that some rights are reserved, Licensing rights subject to conditions<br /> <br /> -Supporting existing licensing practices for RDF resources<br /> <br /> -Supporting these business models: Open data business models, Non open data business models, Hybrid models.<br /> |ReusableOWLBuildingBlock=http://purl.oclc.org/NET/lldr/ns#<br /> |Consequences=A more precise attribution of rights expression to Linked Data<br /> |Scenario=Declaring rights on both Linked Open Data and Linked Closed Data<br /> |SpecializationOf=http://ontologydesignpatterns.org/wiki/Submissions:N-Ary_Relation_Pattern_(OWL_2)<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=http://vocab.deri.ie/void#<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://xmlns.com/foaf/0.1/<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://creativecommons.org/ns#<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://purl.org/dc/terms/<br /> }}<br /> {{Has Element Template<br /> |HasElement=http://purl.org/dc/elements/1.1/<br /> }}<br /> {{Additional information header}}<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2013<br /> }}<br /> {{Submission to event}}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Reviews:MariaPoveda_about_Template_Instance&diff=11225 2012-09-04T08:44:07Z

<p>MariaPoveda: New page: {{Content OP Proposal Review Template |CreationDate=2012/9/4 |SubmittedBy=MariaPoveda |ContentOPUnderReview=Template Instance |RevisionID=11178 |Score=1 - needs minor revision |ReviewSumma...</p> <hr /> <div>{{Content OP Proposal Review Template<br /> |CreationDate=2012/9/4<br /> |SubmittedBy=MariaPoveda<br /> |ContentOPUnderReview=Template Instance<br /> |RevisionID=11178<br /> |Score=1 - needs minor revision<br /> |ReviewSummary=This pattern's aim is to reduce the number of reified instances in an ontology for those cases where the reified properties are identical for multiple entities. <br /> |ReviewConfidence=Medium<br /> |ReviewProblems=In my opinion this pattern could be a reengineering ontology pattern rather than a content pattern. It does not provides solutions for any particular Competency Question or modelling problem.<br /> <br /> In addition the associated building block does not seem to be really reusable. As it only contains one annotation property, it could be easier to reproduce the building block in an ontology rather than to reuse the owl file attached to the pattern. <br /> <br /> Finally, it would be nice to know the rationales for defining &quot;isTemplate&quot; as an annotation property (that has the value True) instead of for example a boolean datatype property.<br /> |ReviewRelevance=Good<br /> |ReviewReusability=Good<br /> |ReviewUnderstandability=Medium<br /> |ReviewClearProblem=Good<br /> |ReviewFigures=Good<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Reviews:MariaPoveda_about_OOPMetrics&diff=11168 2012-08-21T07:04:07Z

<p>MariaPoveda: New page: {{Content OP Proposal Review Template |CreationDate=2012/8/21 |SubmittedBy=MariaPoveda |ContentOPUnderReview=OOPMetrics |RevisionID=11161 |Score=0 - needs major revision |ReviewSummary=The...</p> <hr /> <div>{{Content OP Proposal Review Template<br /> |CreationDate=2012/8/21<br /> |SubmittedBy=MariaPoveda<br /> |ContentOPUnderReview=OOPMetrics<br /> |RevisionID=11161<br /> |Score=0 - needs major revision<br /> |ReviewSummary=The patterns describes numerical values (float and integer) for onject-oriented software metrics.<br /> <br /> The pattern is reusable and general enough.<br /> <br /> There are some revisions needed.<br /> |ReviewConfidence=High<br /> |ReviewProblems=Main comments:<br /> <br /> .- The domain of the relationship &quot;hasMetric&quot; is set as the intersection of serveral classes, namely OOPClass, OOPProject, OOPMethod and OOPPackage. I think it should be defined as the union of theses classes so that if a instance holds this property it is not classified as instance of all these types, that might be disjoint, when running a reasoner over the ontology.<br /> <br /> .- The CPAnnotation schema is not imported in the OWL building block as stated in the call. It would be great if the pattern were annotated using such a schema.<br /> <br /> .- There are no labels nor comments in the OWL code.<br /> <br /> Minor comments:<br /> <br /> .- The already existing domain &quot;software&quot; should be added to the domains field.<br /> <br /> .- The figure could be improved by including the datatype properties.<br /> |ReviewRelevance=Good<br /> |ReviewReusability=Good<br /> |ReviewUnderstandability=Even though the understandability is good, it would be advisable to explain in more detail the solution description.<br /> |ReviewClearProblem=Good<br /> |ReviewClearRelevance=Good<br /> |ReviewFigures=The figure could be improved by including the datatype properties.<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11055 2012-08-03T11:08:42Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=PeriodicIntervalv0.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa, <br /> |Name=PeriodicInterval<br /> |Intent=The goal of this pattern is to represent non-convex intervals where the duration of each internal interval and the duration of the gaps between intervals are constant. These intervals are called periodic intervals within the context of this pattern.<br /> |Domain=Time<br /> |CompetencyQuestion=What is the period of the interval 'every tuesday of 2010'? The period is a week (weekly).<br /> |ContentODPDescription=The class “Interval” defined in the OWL-Time ontol-ogy has been extended within this pattern by means of the class “PeriodicInterval”. This concept has been created in order to define periodic intervals. As we have al-ready mentioned, these intervals are defined by four elements, namely, its beginning, its end, the duration of each subinterval and the duration of the period, that is, the gaps between two subintervals. In order to model the beginning and end of the inter-val, we have reused the relationships “hasBeginning” and “hasEnd” already defined in the OWL-Time ontology. By taking advantage of the concepts and relations al-ready defined in the OWL-Time ontology instead of creating new ones we both pro-mote the reuse of existing models and avoid the inclusion of unnecessary complexity within the pattern being developed. The durations of the subintervals and the period between them have been modelled by means of the relationships “hasIntervalDura-tionPerPeriod” and “hasPeriod” respectively. Both relationships are defined between the concepts “PeriodicInterval” and “DurationDescription”.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/PeriodicInterval.owl<br /> |Consequences=This content pattern allows designers to represent non-convex intervals where the period between subintervals, that is, the gaps between subintervals, and the duration of the subintervals are constant.<br /> |Scenario=Sam teaches every monday<br /> |KnownUse=http://www.oeg-upm.net/index.php/en/ontologies/82-mio-ontologies<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasIntervalDurationPerPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=hasPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=PeriodicInterval<br /> }}<br /> {{Additional information header}}<br /> This ontology design pattern extends the OWL-Time ontology (http://www.w3.org/TR/owl-time) defining periodic intervals.<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2012<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11054 2012-08-03T10:48:53Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=PeriodicIntervalv0.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda<br /> |Name=PeriodicInterval<br /> |Intent=The goal of this pattern is to represent non-convex intervals where the duration of each internal interval and the duration of the gaps between intervals are constant. These intervals are called periodic intervals within the context of this pattern.<br /> |Domain=Time<br /> |CompetencyQuestion=What is the period of the interval 'every tuesday of 2010'? The period is a week (weekly).<br /> |ContentODPDescription=The class “Interval” defined in the OWL-Time ontol-ogy has been extended within this pattern by means of the class “PeriodicInterval”. This concept has been created in order to define periodic intervals. As we have al-ready mentioned, these intervals are defined by four elements, namely, its beginning, its end, the duration of each subinterval and the duration of the period, that is, the gaps between two subintervals. In order to model the beginning and end of the inter-val, we have reused the relationships “hasBeginning” and “hasEnd” already defined in the OWL-Time ontology. By taking advantage of the concepts and relations al-ready defined in the OWL-Time ontology instead of creating new ones we both pro-mote the reuse of existing models and avoid the inclusion of unnecessary complexity within the pattern being developed. The durations of the subintervals and the period between them have been modelled by means of the relationships “hasIntervalDura-tionPerPeriod” and “hasPeriod” respectively. Both relationships are defined between the concepts “PeriodicInterval” and “DurationDescription”.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/PeriodicInterval.owl<br /> |Consequences=This content pattern allows designers to represent non-convex intervals where the period between subintervals, that is, the gaps between subintervals, and the duration of the subintervals are constant.<br /> |Scenario=Sam teaches every monday<br /> |KnownUse=http://www.oeg-upm.net/index.php/en/ontologies/82-mio-ontologies<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasIntervalDurationPerPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=hasPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=PeriodicInterval<br /> }}<br /> {{Additional information header}}<br /> This ontology design pattern extends the OWL-Time ontology (http://www.w3.org/TR/owl-time) defining periodic intervals.<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2012<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11053 2012-08-03T10:47:05Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=PeriodicIntervalv0.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda<br /> |Name=PeriodicInterval<br /> |Intent=The goal of this pattern is to represent non-convex intervals where the duration of each internal interval and the duration of the gaps between intervals are constant. These intervals are called periodic intervals within the context of this pattern.<br /> |Domain=Time<br /> |CompetencyQuestion=What is the period of the interval 'every tuesday of 2010'? The period is a week (weekly).<br /> |ContentODPDescription=The class “Interval” defined in the OWL-Time ontol-ogy has been extended within this pattern by means of the class “PeriodicInterval”. This concept has been created in order to define periodic intervals. As we have al-ready mentioned, these intervals are defined by four elements, namely, its beginning, its end, the duration of each subinterval and the duration of the period, that is, the gaps between two subintervals. In order to model the beginning and end of the inter-val, we have reused the relationships “hasBeginning” and “hasEnd” already defined in the OWL-Time ontology. By taking advantage of the concepts and relations al-ready defined in the OWL-Time ontology instead of creating new ones we both pro-mote the reuse of existing models and avoid the inclusion of unnecessary complexity within the pattern being developed. The durations of the subintervals and the period between them have been modelled by means of the relationships “hasIntervalDura-tionPerPeriod” and “hasPeriod” respectively. Both relationships are defined between the concepts “PeriodicInterval” and “DurationDescription”.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/PeriodicInterval.owl<br /> |Consequences=This content pattern allows designers to represent non-convex intervals where the period between subintervals, that is, the gaps between subintervals, and the duration of the subintervals are constant.<br /> |Scenario=Sam teaches every monday<br /> |KnownUse=http://www.oeg-upm.net/index.php/ontologies/82-mio-ontologies<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasIntervalDurationPerPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=hasPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=PeriodicInterval<br /> }}<br /> {{Additional information header}}<br /> This ontology design pattern extends the OWL-Time ontology (http://www.w3.org/TR/owl-time) defining periodic intervals.<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2012<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11052 2012-08-03T10:22:45Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=PeriodicIntervalv0.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda<br /> |Name=PeriodicInterval<br /> |Intent=The goal of this pattern is to represent non-convex intervals where the duration of each internal interval and the duration of the gaps between intervals are constant. These intervals are called periodic intervals within the context of this pattern.<br /> |Domain=Time<br /> |CompetencyQuestion=What is the period of the interval 'every tuesday of 2010'? The period is a week (weekly).<br /> |ContentODPDescription=The class “Interval” defined in the OWL-Time ontol-ogy has been extended within this pattern by means of the class “PeriodicInterval”. This concept has been created in order to define periodic intervals. As we have al-ready mentioned, these intervals are defined by four elements, namely, its beginning, its end, the duration of each subinterval and the duration of the period, that is, the gaps between two subintervals. In order to model the beginning and end of the inter-val, we have reused the relationships “hasBeginning” and “hasEnd” already defined in the OWL-Time ontology. By taking advantage of the concepts and relations al-ready defined in the OWL-Time ontology instead of creating new ones we both pro-mote the reuse of existing models and avoid the inclusion of unnecessary complexity within the pattern being developed. The durations of the subintervals and the period between them have been modelled by means of the relationships “hasIntervalDura-tionPerPeriod” and “hasPeriod” respectively. Both relationships are defined between the concepts “PeriodicInterval” and “DurationDescription”.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/PeriodicInterval.owl<br /> |Consequences=This content pattern allows designers to represent non-convex intervals where the period between subintervals, that is, the gaps between subintervals, and the duration of the subintervals are constant.<br /> |Scenario=Sam teaches every monday<br /> |KnownUse=mIO! ontology network<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasIntervalDurationPerPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=hasPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=PeriodicInterval<br /> }}<br /> {{Additional information header}}<br /> This ontology design pattern extends the OWL-Time ontology (http://www.w3.org/TR/owl-time) defining periodic intervals.<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2012<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11051 2012-08-03T10:15:44Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation}}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda<br /> |Name=PeriodicInterval<br /> |Intent=The goal of this pattern is to represent non-convex intervals where the duration of each internal interval and the duration of the gaps between intervals are constant. These intervals are called periodic intervals within the context of this pattern.<br /> |Domain=Time<br /> |ContentODPDescription=The class “Interval” defined in the OWL-Time ontol-ogy has been extended within this pattern by means of the class “PeriodicInterval”. This concept has been created in order to define periodic intervals. As we have al-ready mentioned, these intervals are defined by four elements, namely, its beginning, its end, the duration of each subinterval and the duration of the period, that is, the gaps between two subintervals. In order to model the beginning and end of the inter-val, we have reused the relationships “hasBeginning” and “hasEnd” already defined in the OWL-Time ontology. By taking advantage of the concepts and relations al-ready defined in the OWL-Time ontology instead of creating new ones we both pro-mote the reuse of existing models and avoid the inclusion of unnecessary complexity within the pattern being developed. The durations of the subintervals and the period between them have been modelled by means of the relationships “hasIntervalDura-tionPerPeriod” and “hasPeriod” respectively. Both relationships are defined between the concepts “PeriodicInterval” and “DurationDescription”.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/PeriodicInterval.owl<br /> |Consequences=This content pattern allows designers to represent non-convex intervals where the period between subintervals, that is, the gaps between subintervals, and the duration of the subintervals are constant.<br /> |Scenario=Sam teaches every monday<br /> |KnownUse=mIO! ontology network<br /> |SpecializationOf=What is the period of the interval 'every tuesday of 2010'? The period is a week (weekly).<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasIntervalDurationPerPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=hasPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=PeriodicInterval<br /> }}<br /> {{Additional information header}}<br /> This ontology design pattern extends the OWL-Time ontology (http://www.w3.org/TR/owl-time) defining periodic intervals.<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2012<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11050 2012-08-03T10:10:48Z

<p>MariaPoveda: Article is waiting for review.</p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=<br /> }}<br /> {{Content OP Proposal Template<br /> |AlsoKnownAs=Periodic interval content pattern<br /> |SpecializationOf=What is the period of the interval 'every tuesday of 2010'? The period is a week (weekly).<br /> |Scenario=Sam teaches every monday<br /> |Intent=The goal of this pattern is to represent non-convex intervals where the duration of each internal interval and the duration of the gaps between intervals are constant. These intervals are called periodic intervals within the context of this pattern.<br /> |Consequences=This content pattern allows designers to represent non-convex intervals where the period between subintervals, that is, the gaps between subintervals, and the duration of the subintervals are constant.<br /> |SubmittedBy=MariaPoveda<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/PeriodicInterval.owl<br /> |Name=PeriodicInterval<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasIntervalDurationPerPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=hasPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=PeriodicInterval<br /> }}<br /> <br /> {{Additional information header}}<br /> <br /> {{Scenarios about me}}<br /> {{Reviews about me}}{{Modeling issues about me}}{{My references}}<br /> This ontology design pattern extends the OWL-Time ontology (http://www.w3.org/TR/owl-time) defining periodic intervals.<br /> [[Category:Waiting for review]]</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11049 2012-08-03T10:10:06Z

<p>MariaPoveda: Imported from OWL file.</p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=<br /> }}<br /> {{Content OP Proposal Template<br /> |AlsoKnownAs=Periodic interval content pattern<br /> |SpecializationOf=What is the period of the interval 'every tuesday of 2010'? The period is a week (weekly).<br /> |Scenario=Sam teaches every monday<br /> |Intent=The goal of this pattern is to represent non-convex intervals where the duration of each internal interval and the duration of the gaps between intervals are constant. These intervals are called periodic intervals within the context of this pattern.<br /> |Consequences=This content pattern allows designers to represent non-convex intervals where the period between subintervals, that is, the gaps between subintervals, and the duration of the subintervals are constant.<br /> |SubmittedBy=MariaPoveda<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/PeriodicInterval.owl<br /> |Name=PeriodicInterval<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasIntervalDurationPerPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=hasPeriod<br /> }}<br /> {{Has Element Template<br /> |HasElement=PeriodicInterval<br /> }}<br /> <br /> {{Additional information header}}<br /> <br /> {{Scenarios about me}}<br /> {{Reviews about me}}{{Modeling issues about me}}{{My references}}<br /> This ontology design pattern extends the OWL-Time ontology (http://www.w3.org/TR/owl-time) defining periodic intervals.</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11047 2012-08-03T09:38:43Z

<p>MariaPoveda: Imported from OWL file.</p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=<br /> }}<br /> {{Content OP Proposal Template<br /> |AlsoKnownAs=Periodic interval content pattern<br /> |SpecializationOf=What is the period of the interval</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11045 2012-08-03T09:21:36Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=PeriodicIntervalv0.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |AlsoKnownAs=Periodic interval content pattern<br /> |SpecializationOf=What is the period of the interval</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:PeriodicInterval&diff=11041 2012-08-03T09:20:21Z

<p>MariaPoveda: Imported from OWL file.</p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=<br /> }}<br /> {{Content OP Proposal Template<br /> |AlsoKnownAs=Periodic interval content pattern<br /> |SpecializationOf=What is the period of the interval</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:PeriodicIntervalv0.jpg&diff=11040 2012-08-03T08:42:42Z

<p>MariaPoveda: </p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10176 2010-09-29T17:58:14Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Summarization of an inverse n-ary relation<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used to address any of the following situations: <br /> (a) a binary relationship that really needs a further argument. For example to represent the distance between two places.<br /> <br /> (b) two binary relationships that always go together and should be represented as one n-ary relation. For example to represent the value of an observation (e.g. temperature in a patient) and its trend.<br /> <br /> (c) a relationship that is really amongst several things. For example, to represent the spatial location of a person in a given point of time.<br /> <br /> On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary relation where there are distinguished participants. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. This situation can also mean that there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. <br /> <br /> On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Solution=The class &quot;NAryRelationClass&quot; is the class created to support the n-ary relationship (like in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1) and its further relations or attributes. The relationship &quot;mainRelationship&quot; and its inverse have been created to short-circuited the relation between the distinguished participants in the n-ary relationship.<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their services and rarely ask for the relationships about the services and where they are provided.<br /> <br /> <br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10175 2010-09-29T17:17:03Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Summarization of an inverse n-ary relation<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used to address any of the following situations: <br /> (a) a binary relationship that really needs a further argument. For example to represent the distance between two places.<br /> <br /> (b) two binary relationships that always go together and should be represented as one n-ary relation. For example to represent the value of an observation (e.g. temperature in a patient) and its trend.<br /> <br /> (c) a relationship that is really amongst several things. For example, to represent the spatial location of a person in a given point of time.<br /> <br /> On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary relation where there are distinguished participants. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. This situation can also mean that there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. <br /> <br /> On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their services and rarely ask for the relationships about the services and where they are provided.<br /> <br /> <br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:LP-IN-01v1_general.jpg&diff=10174 2010-09-29T16:59:13Z

<p>MariaPoveda: uploaded a new version of &quot;Image:LP-IN-01v1 general.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10173 2010-09-29T16:36:59Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Summarization of an inverse n-ary relation<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used to address any of the following situations: <br /> (a) a binary relationship that really needs a further argument<br /> <br /> (b) two binary relationships that always go together and should be represented as one n-ary relation<br /> <br /> (c) a relationship that is really amongst several things.<br /> <br /> On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary relation where there are distinguished participants. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. This situation can also mean that there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. <br /> <br /> On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their services and rarely ask for the relationships about the services and where they are provided.<br /> <br /> <br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=10168 2010-09-29T09:19:41Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). The main difference between the aggregation relation and other mereological relationships (such as part of or composition) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers.<br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The aggregation relationship between objects, that means that objects can be composed by other objects, is represented by means of the transtive property &quot;hasAggregatedMember&quot; and its inverse &quot;isAggregatedMemberOf&quot;. These properties have as subproperties the non transitive properties &quot;hasDirectAggregatedMember&quot; and its inverse &quot;isDirectAggregatedMemberOf&quot; respectively. By means of this structure of properties we provide a mechanism to represent transitive aggregation relationships (that its, if A has B as aggregated member and B has C as aggregated member then A has C as aggregated member) and to link each aggregated member just to the next level (that its, A has B as direct aggregated member).<br /> <br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have some values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent both simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instantiate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=10167 2010-09-29T09:16:07Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). The main difference between the aggregation relation and other mereological relationships (such as part of or composition) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers.<br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The aggregation relationship between objects, that means that objects can be composed by other objects, is represented by means of the transtive property &quot;hasAggregatedMember&quot; and its inverse &quot;isAggregatedMemberOf&quot;. These properties have as subproperties the non transitive properties &quot;hasDirectAggregatedMember&quot; and its inverse &quot;isDirectAggregatedMemberOf&quot; respectively. By means of this structure of properties we provide a mechanism to represent transitive aggregation relationships (that its, if A has B as aggregated member and B has C as aggregated member then A has C as aggregated member) and to link each aggregated member just to the next level (that its, A has B as direct aggregated member).<br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have some values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent both simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instantiate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=10166 2010-09-29T09:13:37Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). The main difference between the aggregation relation and other mereological relationships (such as part of or composition) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers.<br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The aggregation relationship between objects is represented by means of the transtive &quot;hasAggregatedMember&quot; property and its inverse &quot;isAggregatedMemberOf&quot;. These properties have as subproperties the non transitive properties &quot;hasDirectAggregatedMember&quot; and its inverse &quot;isDirectAggregatedMemberOf&quot; respectively. By means of this structure of properties we provide a mechanism to represent transitive aggregation relationships (that its, if A has B as aggregated member and B has C as aggregated member then A has C as aggregated member) and to link each aggregated member just to the next level (that its, A has B as direct aggregated member).<br /> The aggregation relation between objects means that objects can be composed by other objects.<br /> <br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have some values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent both simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instantiate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=10165 2010-09-29T08:40:23Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). The main difference between the aggregation relation and other mereological relationships (such as part of or composition) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers.<br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The aggregation relationship between objects is represented by means of the transtive &quot;hasAggregatedMember&quot; property and its inverse &quot;isAggregatedMemberOf&quot;. These properties have as subproperties the non transitive properties &quot;hasDirectAggregatedMember&quot; and its inverse &quot;isDirectAggregatedMemberOf&quot; respectively. By means of this structure of properties we can distinguish whether an object is aggregated directly by other objects.<br /> The aggregation relation between objects means that objects can be composed by other objects.<br /> <br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have some values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent both simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instantiate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10164 2010-09-28T16:26:04Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used to address any of the following situations: <br /> (a) a binary relationship really needs a further argument<br /> <br /> (b) two binary relationships always go together and should be represented as one n-ary relation<br /> <br /> (c) a relationship that is really amongst several things.<br /> <br /> On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments.<br /> <br /> On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> <br /> <br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10163 2010-09-28T16:20:43Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; or (c) a relationship that is really amongst several things.<br /> On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments.<br /> <br /> On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10162 2010-09-28T16:18:57Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments.<br /> <br /> On the other hand, the motivation is to provide a shorcut for queries that involve the distinguished participants in the n-ary relationship. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10161 2010-09-28T16:18:20Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> On the one hand, the motivation of this pattern is to express the inverse relationship of an n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments.<br /> <br /> On the other hand, this pattern is intended to speed up the queries involving the distinguished participants in the n-ary relationship.<br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:N_aria_provider_service.JPG&diff=10160 2010-09-28T16:10:21Z

<p>MariaPoveda: uploaded a new version of &quot;Image:N aria provider service.JPG&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=10158 2010-09-28T15:24:23Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa,<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). The main difference between the aggregation relation and other mereological relationships (such as part of or composition) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers.<br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The relationship of aggregation between objects is represented by means of the &quot;hasAggregatedMember&quot; property and its inverse &quot;isAggregatedMemberOf&quot;.<br /> <br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have some values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instantiate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=10157 2010-09-28T15:20:12Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa,<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). The main difference between the aggregation relation and other mereological relationships (such as part of or composition) is that the aggregated object and its aggregated members should belong to the same concept. For example, a turbine is part of an engine, whereas an aggregated provider is formed by providers.<br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The relationship of aggregation between objects is represented by means of the &quot;hasAggregatedMember&quot; property and its inverse &quot;isAggregatedMemberOf&quot;.<br /> <br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have some values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instanciate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:ResourceSoA.jpg&diff=10155 2010-09-28T15:01:59Z

<p>MariaPoveda: uploaded a new version of &quot;Image:ResourceSoA.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:ContextSourceSoA.jpg&diff=10154 2010-09-28T14:56:07Z

<p>MariaPoveda: uploaded a new version of &quot;Image:ContextSourceSoA.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:ServiceProviderSoA_v1.jpg&diff=10153 2010-09-28T14:49:53Z

<p>MariaPoveda: uploaded a new version of &quot;Image:ServiceProviderSoA v1.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:CP-SoA-01v1.jpg&diff=10152 2010-09-28T14:41:22Z

<p>MariaPoveda: uploaded a new version of &quot;Image:CP-SoA-01v1.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:CP-SoA-01v1.jpg&diff=10151 2010-09-28T14:40:05Z

<p>MariaPoveda: uploaded a new version of &quot;Image:CP-SoA-01v1.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:CP-SoA-01v1.jpg&diff=10150 2010-09-28T14:09:41Z

<p>MariaPoveda: uploaded a new version of &quot;Image:CP-SoA-01v1.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:LP-IN-01v1_general.jpg&diff=10149 2010-09-28T13:05:28Z

<p>MariaPoveda: uploaded a new version of &quot;Image:LP-IN-01v1 general.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10148 2010-09-28T10:20:39Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> [[Image:N_aria_provider_service.JPG]]<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10147 2010-09-28T10:20:25Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> [[Image:N_aria_provider_service.JPG]]<br /> <br /> |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:N_aria_provider_service.JPG&diff=10146 2010-09-28T10:17:35Z

<p>MariaPoveda: </p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10145 2010-09-28T09:49:09Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as additional arguments. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=10144 2010-09-28T09:43:50Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exists mainly between two entities and the rest of entities involved in the relationship can be considered as just additional, and probably optional, arguments. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this pattern could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the queries executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg<br /> |Consequences=The main advantage of this pattern is that allows asking for those services that are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=File:LP-IN-01v1_general.jpg&diff=10143 2010-09-28T09:24:15Z

<p>MariaPoveda: uploaded a new version of &quot;Image:LP-IN-01v1 general.jpg&quot;</p> <hr /> <div></div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=10142 2010-09-28T08:59:18Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa,<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole). The main difference between the aggregation and other mereological relationships (e.g. part of, composition) is that the aggregated object and its aggregated members belong to the same concept. For example, a turbine is part of an engine but an aggregated provider is formed by providers. <br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The relationship of aggregation between objects is represented by means of the &quot;hasAggregatedMember&quot; property and its inverse &quot;isAggregatedMemberOf&quot;.<br /> <br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have at least two values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instanciate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers. A context source can be simple or be an aggregate of a set of context sources. A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Review assigned]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=9964 2010-09-02T08:41:18Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation. This means that the relationship exits mainly between two entities and the rest of entities involved in the relationship can be consider as simple, and probably optional, arguments. <br /> <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this patter could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the querys executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg<br /> |Consequences=The main advantage of this pattern is that allows asking for those services taht are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=9963 2010-09-02T08:37:15Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants, that is, there is a single individual standing out as the subject or the &quot;owner&quot; of the relation or the relationship exits mainly between two entities and the rest of the entities involved in the relationship could be consider simple, and probably optional, arguments. <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this patter could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1.<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and their inverse between two distinguished participants without a complex query (that would involve the class created to support the n-ary relation between the origin and destination classes of the n-ary relationship).<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that a service provider provides a service at a place in a given period of time with a particular price. The model should also represent that a service is offered by a provider. <br /> We have also observed that the querys executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg<br /> |Consequences=The main advantage of this pattern is that allows asking for those services taht are provided by a service provider and vice-versa without a complex query (that would involve the class created to support the n-ary relation between service providers and services).<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=9960 2010-09-02T06:28:45Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants. <br /> This pattern is inspired on the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2. The difference in our case is that there are at least two distinguished participants into the relationship. Therefore this patter could be considered as an extension of the third consideration shown in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 applied to the use case of n-ary relationships described in http://www.w3.org/TR/swbp-n-aryRelations/#useCase1. <br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and its inverse between two distinguished participants without a complex query involving the class created to support the n-ary relation between the origin and destiantion classes of the n-ary relationship. <br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that the service providers provide a service at a place in a given period of time with a price. Also is needed represent that a service is offered by a provider. Also, we have observed that the querys executed by our applications often ask for the relationship between providers and their service and rarely ask for the relationships about the services and where they are provided.<br /> |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg<br /> |Consequences=The main advantage of this pattern is that allows to ask for which services are provided by a service provider and vice versa without a complex query involving the class created to support the n-ary relation between service providers and services.<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation (http://www.w3.org/TR/swbp-n-aryRelations/#pattern1) and the third consideration in http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:Summarization_of_an_inverse_n-ary_relation&diff=9959 2010-09-02T06:02:16Z

<p>MariaPoveda: </p> <hr /> <div>{{Logical_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=LP-IN-01v1_general.jpg<br /> }}<br /> {{Logical OP General Template<br /> |Name=Inverse n-ary relationship<br /> |SubmittedBy=MariaPoveda, MariCarmenSuarezFigueroa,<br /> |Author=MariaPoveda, MariCarmenSuarezFigueroa,<br /> }}<br /> {{Logical OP Description Template<br /> |Motivation=The n-ary relationships should be used when: (a) a binary relationship really needs a further argument; (b) two binary relationships always go together and should be represented as one n-ary relation; (c) a relationship that is really amongst several things.<br /> The motivation of this pattern is to express the inverse relationship of a n-ary one where there are distinguished participants. This patterns is inspired on the http://www.w3.org/TR/swbp-n-aryRelations/#choosingPattern1or2 pattern<br /> |Aim=The aim of this pattern is to allow asking for n-ary relationships and its inverse without a complex query involving the class created to support the n-ary relation between the origin and destiantion classes of the n-ary relationship.<br /> |Elements=Class, Relationship, Attribute and inverseOf<br /> }}<br /> {{Logical OP Example Template<br /> |ProblemExample=We might want to represent that the service providers provide a service at a place in a given period of time with a price. Also is needed represent that a service is offered by a provider.<br /> |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:LP-IN-01v1.jpg<br /> |Consequences=The main advantage of this pattern is that allows to ask for which services are provided by a service provider and vice versa without a complex query involving the class created to support the n-ary relation between service providers and services.<br /> }}<br /> {{Logical OP Reference Template<br /> |Origin=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |RelatedTo=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> |InCombination=Logical Pattern for Modelling N-ary Relation: Introducing a New Class for the Relation<br /> }}<br /> {{Additional information header}}<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda http://ontologydesignpatterns.org/index.php?title=Submissions:SimpleOrAggregated&diff=9956 2010-09-01T17:25:32Z

<p>MariaPoveda: </p> <hr /> <div>{{Content_OP_Proposal_toolbar}}<br /> {{Graphical representation header}}<br /> {{Graphical representation<br /> |ImageName=CP-SoA-01v1.jpg<br /> }}<br /> {{Content OP Proposal Template<br /> |SubmittedBy=MariaPoveda, MariCarmenDeFigueroa,<br /> |Name=SimpleOrAggregated<br /> |Intent=The goal of this pattern is to represent in a non-transitive fashion objects that can be simple or aggregated (that is, several objects gathered in another object acting as a whole).<br /> |Domain=Parts and Collections,<br /> |CompetencyQuestion=What elements are aggregated members of this object?, What is this object aggregated member of?<br /> |ContentODPDescription=The class &quot;ObjectByCardinality&quot; has been created to classify simple and aggregated objects into its subclasses &quot;SimpleObject&quot; and &quot;AggregatedObject&quot;, respectively. These subclasses are disjoint among them. <br /> The relationship of aggregation between objects is represented by means of the &quot;hasAggregatedMember&quot; property and its inverse &quot;isAggregatedMemberOf&quot;.<br /> <br /> Finally, the class &quot;AggregatedObject&quot; has been defined as equivalent to those things that have at least two values for the property &quot;hasAggregatedMember&quot; with the aim of allowing the automatic classification of aggregated objects in this class when a reasoner is applied.<br /> |ReusableOWLBuildingBlock=http://delicias.dia.fi.upm.es/ontologies/SimpleOrAggregated.owl<br /> |Consequences=This Content OP allows designers to represent simple individuals of a given concept (that is, an individual that is made up of itself) and aggregated individuals of a given concept (that is, an individual that is made up of several individuals of the same concept). <br /> In summary, this pattern allows to represent both simple objects and aggregated objects and their members.<br /> In addition, this pattern can be used to detect the following contradictory situation by means of applying a reasoner: 'to instanciate the relationship &quot;hasAggregatedMember&quot; for an Object that belongs to &quot;SimpleObject&quot;'. This situation represents a consistency error and it is detected when a resoner is applied due to the following modelling decisions included in the pattern: (a) &quot;AggregatedObject&quot; class represents the &quot;hasAggregatedMember&quot; domain and (b) it is disjoint with &quot;SimpleObject&quot;.<br /> |Scenario=A service provider can be simple or be an aggregate of a set of service providers.<br /> A context source can be simple or be an aggregate of a set of context sources.<br /> <br /> A computing or storage resource can be simple or be an aggregate of a set of computing or storage resources.<br /> }}<br /> {{Element list header}}<br /> {{Has Element Template<br /> |HasElement=hasAggregatedMember<br /> }}<br /> {{Has Element Template<br /> |HasElement=isAggregatedMemberOf<br /> }}<br /> {{Has Element Template<br /> |HasElement=AggregatedObject<br /> }}<br /> {{Has Element Template<br /> |HasElement=Object<br /> }}<br /> {{Has Element Template<br /> |HasElement=ObjectByCardinality<br /> }}<br /> {{Has Element Template<br /> |HasElement=SimpleObject<br /> }}<br /> {{Additional information header}}<br /> [[Category:Waiting for review]]<br /> {{Scenarios about me}}<br /> {{Reviews about me}}<br /> {{Modeling issues about me}}<br /> {{My references}}<br /> {{Submission to event<br /> |Event=WOP:2010<br /> }}</div>

MariaPoveda