Hi, @Frank :) ... accidentally followed the list.. and could not resist adding some 5 cents ..:)
What would be the purpose of RELS-INT in general? Sorry to pull-into the discussion as an alien :) * The possibility to specify the datastream cardinality may be expressed within the structural part of Fedora cModel (no need for RELS-INT here) * I read Steve mentioned named graph of objects -> this may actually be of a bit better use for the community :) * In general one mostly understands datastreams of Fedora objects as internal parts of the object (therefore, these are not things on their own :) * but what one indeed needs is named parts of "compound" objects -> which would be the way towards the named graph Cheers, Natasa -- Natasa Bulatovic Max Planck Digital Library (MPDL) Amalienstrasse 33 80799 Munich, Germany http://www.mpdl.mpg.de e-Mail: [email protected] phone: +49-89-38602-223 fax: +49-89-38602-280 [email protected] wrote: > Send Fedora-commons-developers mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Fedora-commons-developers digest..." > > > Today's Topics: > > 1. Re: How RELS-INT breaks the Fedora paradigm and opens the > door for new and innovative solutions to old problems > (Schwichtenberg, Frank) > 2. Re: How RELS-INT breaks the Fedoraparadigm and opens the door > for new and innovative solutionsto old problems (Steve Bayliss) > 3. Re: How RELS-INT breaks the Fedora paradigm and opens the > door for new and innovative solutions to old problems > (Asger Blekinge-Rasmussen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Jul 2009 12:14:05 +0200 > From: "Schwichtenberg, Frank" <[email protected]> > Subject: Re: [Fedora-commons-developers] How RELS-INT breaks the > Fedora paradigm and opens the door for new and innovative solutions > to > old problems > To: "Asger Blekinge-Rasmussen" <[email protected]>, > <[email protected]> > Message-ID: > <561b608813f3e7448d792a51ef2ab03e04f11...@excluster.fiz-karlsruhe.de> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Asger, > I absolutely agree with you. That seems to be the logical enhancement of > Enhanced Content Models. :-) > > I just wonder if the idea of RELS-EXT and RELS-INT holds. So, you are right > pointing out datastreams are entities (or objects), now. They have URIs and > it is possible to make statements in RELS-INT with datastreams of other > Fedora objects as object(-of-the-statement). So far your idea to enhance > Enhanced Content Models, which is great I think. > > My criticism on "the idea of RELS-EXT and RELS-INT" would be: One can refer > datastreams extern to the Fedora object the RELS-INT belongs to. And it is > possible to refer entire Fedora objects from RELS-INT. Obviously it is > possible to refer datastreams from RELS-EXT, also such of the Fedora object > the RELS-EXT belongs to. So "EXT" and "INT" seems to be out-dated. The > difference between RELS-EXT and RELS-INT has nothing to do with relations to > external or internal entities. But with making statements about the object > (RELS-EXT) or about parts of the object (RELS-INT). So datastream URIs in > statements (both in RELS-EXT and RELS-INT) bring in possible complexity. > > I don't want to say that's bad; just thoughts. Maybe that is something people > are waiting for. And the possibility to specify datastream cardinality (maybe > min and max) is great. > > Maybe that just brings us back to the question, why not just allow > datastreams of RDF/XML content which are automatically get propagated to the > resource index. > > Regards, Frank > > >> -----Urspr?ngliche Nachricht----- >> Von: Asger Blekinge-Rasmussen [mailto:[email protected]] >> Gesendet: Freitag, 3. Juli 2009 20:39 >> An: [email protected] >> Betreff: [Fedora-commons-developers] How RELS-INT breaks the Fedora >> paradigm and opens the door for new and innovative solutions to old >> problems >> >> Hi >> >> Steve Bayliss have just finished adding the RELS-INT datastream to >> Fedora, as announced on this list. I have been in some discussion with >> him, as also shown on this list. This discussion have granted me a >> chance to fully understand the conceptual change that RELS-INT brings. >> >> In the semantic web paradigm, everything with an URI is a thing, which >> can have properties and so on. But in Fedora, so far only Objects could >> have properties (relations) >> >> This all changed with the introduction of RELS-INT. Steve Bayliss have >> made a system for, in a fedora object, specifying object properties >> with >> a datastream id as subject. No more, no less. >> >> So datastreams are now objects, so to speak. They have a URI, and they >> can have properties themselves. Formerly, there was the Fedora Object, >> which had datastreams (blobs of data) and properties. Now there is the >> Datastream, which has ONE blob of data, and properties. Fedora objects >> now has a list of Datastreams, and properties for the object itself. >> So we have two levels of objects. This is the way the Fedora paradigm >> is >> broken. >> >> Big deal? Yes. Because if the datastreams can have relations, they can >> have the hasModel/rdf:type relation. So, suddently we have a framework >> for talking about the classes of datastreams. Now, like the content >> models, there is the possibility to specify restrictions and demands on >> the datastream, both it's relations and it's content. >> >> Some might remember the old problem with the DS-COMPOSITE-MODEL >> datastream. There is no way to specify datastreams that might be there, >> only datastreams that have to be there, and there is no way to specify >> cardinality for datastreams. >> With the use of RELS-INT and enhanced content models, we can now >> specify >> something close to a solution to this problem. >> Enhanced Content Models give the ability to define an ontology for >> subscribing objects. This could include relations from the object to >> the >> objects datastreams. On such relations, Enhanced COntent Models give >> the >> ability to make cardinality demands, and specify the class/content >> model >> of range. >> So, in the RELS-EXT for an object you could make this blob >> >> <rdf:Description rdf:about="info:fedora/demo:object1"> >> <fedora-system:hasModel rdf:resource="info:fedora/demo:cm1"/> >> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC1"/> >> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC2"/> >> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC3"/> >> </rdf:Description> >> >> Then in the ontology we would specify something like >> <owl:Class rdf:about="info:fedora/doms:ContentModel_DOMS"> >> >> <rdfs:subClassOf> >> <owl:Restriction> >> <owl:onProperty rdf:resource="#hasDCdatastream"/> >> <owl:minCardinality >> rdf:datatype="http://www.w3.org/2001/XMLSchema#integer";>3</owl:minCardi >> nality> >> </owl:Restriction> >> </rdfs:subClassOf> >> <rdfs:subClassOf> >> <owl:Restriction> >> <owl:onProperty rdf:resource="#hasDCdatastream"/> >> <owl:allValuesFrom >> >> rdf:resource="info:fedora/demo:DCdatastreamcontentModel"/> >> </owl:Restriction> >> </rdfs:subClassOf> >> </owl:Class> >> This basically says that demo:object1 must have at least three >> hasDCdatastream relations to things of the type >> demo:DCdatastreamcontentModel >> >> This in the RELS-INT in demo:object1 >> <rdf:Description rdf:about="info:fedora/demo:object1/DC1"> >> <fedora-system:hasModel >> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >> </rdf:Description> >> <rdf:Description rdf:about="info:fedora/demo:object1/DC2"> >> <fedora-system:hasModel >> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >> </rdf:Description> >> <rdf:Description rdf:about="info:fedora/demo:object1/DC3"> >> <fedora-system:hasModel >> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >> </rdf:Description> >> >> >> And voila, you have specified that objects of demo:cm1 must have at >> least three datastreams, which all have a specific content model. >> >> >> I have not fully thought everything above through, but I hope you get >> the gist of it. I would like to hear other peoples thoughts on this. >> Think of this as a preliminary on how RELS-INT can be used in enhanced >> content models >> >> Regards >> Asger >> >> Enhanced content models to be found on ecm.sourceforge.net >> >> >> >> ----------------------------------------------------------------------- >> ------- >> _______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> > > > ------------------------------------------------------- > > Fachinformationszentrum Karlsruhe, Gesellschaft f?r > wissenschaftlich-technische Information mbH. > Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB > 101892. > Gesch?ftsf?hrerin: Sabine Br?nger-Weilandt. > Vorsitzender des Aufsichtsrats: MinR Hermann Riehl. > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 6 Jul 2009 12:12:34 +0100 > From: "Steve Bayliss" <[email protected]> > Subject: Re: [Fedora-commons-developers] How RELS-INT breaks the > Fedoraparadigm and opens the door for new and innovative > solutionsto > old problems > To: "'Schwichtenberg, Frank'" <[email protected]>, > "'Asger Blekinge-Rasmussen'" <[email protected]>, > <[email protected]> > Message-ID: <007801c9fe2a$ab531480$04010...@asusp4t533> > Content-Type: text/plain; charset="iso-8859-1" > > Datastreams had URIs prior to RELS-INT - and there are some triples > automatically created with datastreams as subject (mime-type, format-uri, > last modified date, etc) - so I'm not sure that RELS-INT per se changes what > datastreams "are" in terms of if they are entities or objects. I would see > it just as enhancing the descriptions that can be applied within the > existing digital object model (rather than a change to the model). > > In terms of "INT" and "EXT", then yes maybe the terminology is not quite > correct. What we are talking about is "Statements about [having a subject] > digital objects" and "Statements about [having a subject] datastreams". > > >> Maybe that just brings us back to the question, why not just allow >> > datastreams of RDF/XML content > >> which are automatically get propagated to the resource index. >> > > One important point on this is that the resource index is a single RDF > graph, and it's not possible to (directly) identify which triples have been > created by which digital object (or which RELS-EXT or RELS-INT datastream) > in the general case. > > Thus in a general RDF/XML datastream case it could be possible for object A > and object B to assert the same triple. Then if object B retracts the > assertion (eg gets deleted); the triple gets deleted, even though object A > is still asserting it. So this would lead to the need to examine the > RELS-EXT/RELS-INT of *every* object every time a change is made, to > determine the impact on the triples in the resource index. > > That's the idea behind some of the restrictions on RELS-EXT (and RELS-INT) - > if the subject of the triple is scoped to the digital object in which > RELS-EXT or RELS-INT resides, then this problem goes away. > > Of course that's not the only solution... a named graph approach could also > be used, but this would be a fairly radical change to what's implemented at > the moment. > > Steve > > > > > -----Original Message----- > From: Schwichtenberg, Frank [mailto:[email protected]] > Sent: 06 July 2009 11:14 > To: Asger Blekinge-Rasmussen; > [email protected] > Subject: Re: [Fedora-commons-developers] How RELS-INT breaks the > Fedoraparadigm and opens the door for new and innovative solutionsto old > problems > > > Hi Asger, > I absolutely agree with you. That seems to be the logical enhancement of > Enhanced Content Models. :-) > > I just wonder if the idea of RELS-EXT and RELS-INT holds. So, you are right > pointing out datastreams are entities (or objects), now. They have URIs and > it is possible to make statements in RELS-INT with datastreams of other > Fedora objects as object(-of-the-statement). So far your idea to enhance > Enhanced Content Models, which is great I think. > > My criticism on "the idea of RELS-EXT and RELS-INT" would be: One can refer > datastreams extern to the Fedora object the RELS-INT belongs to. And it is > possible to refer entire Fedora objects from RELS-INT. Obviously it is > possible to refer datastreams from RELS-EXT, also such of the Fedora object > the RELS-EXT belongs to. So "EXT" and "INT" seems to be out-dated. The > difference between RELS-EXT and RELS-INT has nothing to do with relations to > external or internal entities. But with making statements about the object > (RELS-EXT) or about parts of the object (RELS-INT). So datastream URIs in > statements (both in RELS-EXT and RELS-INT) bring in possible complexity. > > I don't want to say that's bad; just thoughts. Maybe that is something > people are waiting for. And the possibility to specify datastream > cardinality (maybe min and max) is great. > > Maybe that just brings us back to the question, why not just allow > datastreams of RDF/XML content which are automatically get propagated to the > resource index. > > Regards, Frank > > >> -----Urspr?ngliche Nachricht----- >> Von: Asger Blekinge-Rasmussen [mailto:[email protected]] >> Gesendet: Freitag, 3. Juli 2009 20:39 >> An: [email protected] >> Betreff: [Fedora-commons-developers] How RELS-INT breaks the Fedora >> paradigm and opens the door for new and innovative solutions to old >> problems >> >> Hi >> >> Steve Bayliss have just finished adding the RELS-INT datastream to >> Fedora, as announced on this list. I have been in some discussion with >> him, as also shown on this list. This discussion have granted me a >> chance to fully understand the conceptual change that RELS-INT brings. >> >> In the semantic web paradigm, everything with an URI is a thing, which >> can have properties and so on. But in Fedora, so far only Objects >> could have properties (relations) >> >> This all changed with the introduction of RELS-INT. Steve Bayliss have >> made a system for, in a fedora object, specifying object properties >> with a datastream id as subject. No more, no less. >> >> So datastreams are now objects, so to speak. They have a URI, and they >> can have properties themselves. Formerly, there was the Fedora Object, >> which had datastreams (blobs of data) and properties. Now there is the >> Datastream, which has ONE blob of data, and properties. Fedora objects >> now has a list of Datastreams, and properties for the object itself. >> So we have two levels of objects. This is the way the Fedora paradigm >> is broken. >> >> Big deal? Yes. Because if the datastreams can have relations, they can >> have the hasModel/rdf:type relation. So, suddently we have a framework >> for talking about the classes of datastreams. Now, like the content >> models, there is the possibility to specify restrictions and demands >> on the datastream, both it's relations and it's content. >> >> Some might remember the old problem with the DS-COMPOSITE-MODEL >> datastream. There is no way to specify datastreams that might be >> there, only datastreams that have to be there, and there is no way to >> specify cardinality for datastreams. With the use of RELS-INT and >> enhanced content models, we can now specify >> something close to a solution to this problem. >> Enhanced Content Models give the ability to define an ontology for >> subscribing objects. This could include relations from the object to >> the >> objects datastreams. On such relations, Enhanced COntent Models give >> the >> ability to make cardinality demands, and specify the class/content >> model >> of range. >> So, in the RELS-EXT for an object you could make this blob >> >> <rdf:Description rdf:about="info:fedora/demo:object1"> >> <fedora-system:hasModel rdf:resource="info:fedora/demo:cm1"/> >> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC1"/> >> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC2"/> >> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC3"/> >> </rdf:Description> >> >> Then in the ontology we would specify something like <owl:Class >> rdf:about="info:fedora/doms:ContentModel_DOMS"> >> >> <rdfs:subClassOf> >> <owl:Restriction> >> <owl:onProperty rdf:resource="#hasDCdatastream"/> >> <owl:minCardinality >> rdf:datatype="http://www.w3.org/2001/XMLSchema#integer";>3</owl:minCard >> i >> nality> >> </owl:Restriction> >> </rdfs:subClassOf> >> <rdfs:subClassOf> >> <owl:Restriction> >> <owl:onProperty rdf:resource="#hasDCdatastream"/> >> <owl:allValuesFrom >> >> rdf:resource="info:fedora/demo:DCdatastreamcontentModel"/> >> </owl:Restriction> >> </rdfs:subClassOf> >> </owl:Class> >> This basically says that demo:object1 must have at least three >> hasDCdatastream relations to things of the type >> demo:DCdatastreamcontentModel >> >> This in the RELS-INT in demo:object1 >> <rdf:Description rdf:about="info:fedora/demo:object1/DC1"> >> <fedora-system:hasModel >> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >> </rdf:Description> >> <rdf:Description rdf:about="info:fedora/demo:object1/DC2"> >> <fedora-system:hasModel >> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >> </rdf:Description> >> <rdf:Description rdf:about="info:fedora/demo:object1/DC3"> >> <fedora-system:hasModel >> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >> </rdf:Description> >> >> >> And voila, you have specified that objects of demo:cm1 must have at >> least three datastreams, which all have a specific content model. >> >> >> I have not fully thought everything above through, but I hope you get >> the gist of it. I would like to hear other peoples thoughts on this. >> Think of this as a preliminary on how RELS-INT can be used in enhanced >> content models >> >> Regards >> Asger >> >> Enhanced content models to be found on ecm.sourceforge.net >> >> >> >> ---------------------------------------------------------------------- >> - >> ------- >> _______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> > > > ------------------------------------------------------- > > Fachinformationszentrum Karlsruhe, Gesellschaft f?r > wissenschaftlich-technische Information mbH. > Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB > 101892. > Gesch?ftsf?hrerin: Sabine Br?nger-Weilandt. > Vorsitzender des Aufsichtsrats: MinR Hermann Riehl. > > > > ---------------------------------------------------------------------------- > -- > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > > > > ------------------------------ > > Message: 3 > Date: Mon, 6 Jul 2009 14:10:40 +0200 > From: Asger Blekinge-Rasmussen <[email protected]> > Subject: Re: [Fedora-commons-developers] How RELS-INT breaks the > Fedora paradigm and opens the door for new and innovative solutions to > old problems > To: "Schwichtenberg, Frank" <[email protected]> > Cc: "[email protected]" > <[email protected]> > Message-ID: <1246882240.4381.89.ca...@pc284> > Content-Type: text/plain; charset="UTF-8" > > Hi Frank > > Thanks for the reply. > > Yes, you definitely nailed down the the missing points. > > RELS-INT and RELS-EXT are misnamed, for the very reason you wrote. No > contest there. > > About the RELS-EXT relations to datastreams in the object, that was a > hack. > A fedora object has some relation, fedora-view:disseminates I think, to > each datastream belonging to this object. Since this is the same > relation to every datastream, it is not possible to define a OWL > allValuesFrom restriction. In fact it is possible, but it has the effect > of demanding that all datastreams in the object is of the specified > class. Similarly, cardinality on that relation can only specify the > total number of datastreams. > I got around this by making my own relation (in RELS-EXT) to the > datastreams in the same object, but as you point out, these relations > could go to datastreams in another object. > > Anyway, the introduction of RELS-INT does bring the current object > serialisation (foxml) into question. A datastream object conceptually > contains > A ID > Object properties (in RELS-INT) > Content (In the datastream proper) > Versioning (In the datastream proper) > Audit trail (in the AUDIT datastream in the Object) > > So a datastream object are serialised into three datastreams, it self, > RELS-INT and AUDIT. And the fedora object then gets a relation to this > object. > To accomadate the new conceptual structure, it would probably be simpler > to serialise each datastream to it's own xml file, and make links from > the fedora object to each datastream it "contains". > The problem with this approach is that the traditional Fedora objects > will just become a collection of datastreams, and properties about this > collection, and not data in itself. This could easily be modelled with a > datastream object, and thus we have come full circle. Objects will in > effect reduced to having just one datastream. > This idea is starting to scare me somewhat.... > > Regards > > > > On Mon, 2009-07-06 at 12:14 +0200, Schwichtenberg, Frank wrote: > >> Hi Asger, >> I absolutely agree with you. That seems to be the logical enhancement of >> Enhanced Content Models. :-) >> >> I just wonder if the idea of RELS-EXT and RELS-INT holds. So, you are right >> pointing out datastreams are entities (or objects), now. They have URIs and >> it is possible to make statements in RELS-INT with datastreams of other >> Fedora objects as object(-of-the-statement). So far your idea to enhance >> Enhanced Content Models, which is great I think. >> >> My criticism on "the idea of RELS-EXT and RELS-INT" would be: One can refer >> datastreams extern to the Fedora object the RELS-INT belongs to. And it is >> possible to refer entire Fedora objects from RELS-INT. Obviously it is >> possible to refer datastreams from RELS-EXT, also such of the Fedora object >> the RELS-EXT belongs to. So "EXT" and "INT" seems to be out-dated. The >> difference between RELS-EXT and RELS-INT has nothing to do with relations to >> external or internal entities. But with making statements about the object >> (RELS-EXT) or about parts of the object (RELS-INT). So datastream URIs in >> statements (both in RELS-EXT and RELS-INT) bring in possible complexity. >> >> I don't want to say that's bad; just thoughts. Maybe that is something >> people are waiting for. And the possibility to specify datastream >> cardinality (maybe min and max) is great. >> >> Maybe that just brings us back to the question, why not just allow >> datastreams of RDF/XML content which are automatically get propagated to the >> resource index. >> >> Regards, Frank >> >> >>> -----Urspr?ngliche Nachricht----- >>> Von: Asger Blekinge-Rasmussen [mailto:[email protected]] >>> Gesendet: Freitag, 3. Juli 2009 20:39 >>> An: [email protected] >>> Betreff: [Fedora-commons-developers] How RELS-INT breaks the Fedora >>> paradigm and opens the door for new and innovative solutions to old >>> problems >>> >>> Hi >>> >>> Steve Bayliss have just finished adding the RELS-INT datastream to >>> Fedora, as announced on this list. I have been in some discussion with >>> him, as also shown on this list. This discussion have granted me a >>> chance to fully understand the conceptual change that RELS-INT brings. >>> >>> In the semantic web paradigm, everything with an URI is a thing, which >>> can have properties and so on. But in Fedora, so far only Objects could >>> have properties (relations) >>> >>> This all changed with the introduction of RELS-INT. Steve Bayliss have >>> made a system for, in a fedora object, specifying object properties >>> with >>> a datastream id as subject. No more, no less. >>> >>> So datastreams are now objects, so to speak. They have a URI, and they >>> can have properties themselves. Formerly, there was the Fedora Object, >>> which had datastreams (blobs of data) and properties. Now there is the >>> Datastream, which has ONE blob of data, and properties. Fedora objects >>> now has a list of Datastreams, and properties for the object itself. >>> So we have two levels of objects. This is the way the Fedora paradigm >>> is >>> broken. >>> >>> Big deal? Yes. Because if the datastreams can have relations, they can >>> have the hasModel/rdf:type relation. So, suddently we have a framework >>> for talking about the classes of datastreams. Now, like the content >>> models, there is the possibility to specify restrictions and demands on >>> the datastream, both it's relations and it's content. >>> >>> Some might remember the old problem with the DS-COMPOSITE-MODEL >>> datastream. There is no way to specify datastreams that might be there, >>> only datastreams that have to be there, and there is no way to specify >>> cardinality for datastreams. >>> With the use of RELS-INT and enhanced content models, we can now >>> specify >>> something close to a solution to this problem. >>> Enhanced Content Models give the ability to define an ontology for >>> subscribing objects. This could include relations from the object to >>> the >>> objects datastreams. On such relations, Enhanced COntent Models give >>> the >>> ability to make cardinality demands, and specify the class/content >>> model >>> of range. >>> So, in the RELS-EXT for an object you could make this blob >>> >>> <rdf:Description rdf:about="info:fedora/demo:object1"> >>> <fedora-system:hasModel rdf:resource="info:fedora/demo:cm1"/> >>> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC1"/> >>> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC2"/> >>> <demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC3"/> >>> </rdf:Description> >>> >>> Then in the ontology we would specify something like >>> <owl:Class rdf:about="info:fedora/doms:ContentModel_DOMS"> >>> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="#hasDCdatastream"/> >>> <owl:minCardinality >>> rdf:datatype="http://www.w3.org/2001/XMLSchema#integer";>3</owl:minCardi >>> nality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="#hasDCdatastream"/> >>> <owl:allValuesFrom >>> >>> rdf:resource="info:fedora/demo:DCdatastreamcontentModel"/> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> </owl:Class> >>> This basically says that demo:object1 must have at least three >>> hasDCdatastream relations to things of the type >>> demo:DCdatastreamcontentModel >>> >>> This in the RELS-INT in demo:object1 >>> <rdf:Description rdf:about="info:fedora/demo:object1/DC1"> >>> <fedora-system:hasModel >>> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >>> </rdf:Description> >>> <rdf:Description rdf:about="info:fedora/demo:object1/DC2"> >>> <fedora-system:hasModel >>> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >>> </rdf:Description> >>> <rdf:Description rdf:about="info:fedora/demo:object1/DC3"> >>> <fedora-system:hasModel >>> rdf:resource="info:fedora/demo:DCdatastramcontentModel"/> >>> </rdf:Description> >>> >>> >>> And voila, you have specified that objects of demo:cm1 must have at >>> least three datastreams, which all have a specific content model. >>> >>> >>> I have not fully thought everything above through, but I hope you get >>> the gist of it. I would like to hear other peoples thoughts on this. >>> Think of this as a preliminary on how RELS-INT can be used in enhanced >>> content models >>> >>> Regards >>> Asger >>> >>> Enhanced content models to be found on ecm.sourceforge.net >>> >>> >>> >>> ----------------------------------------------------------------------- >>> ------- >>> _______________________________________________ >>> Fedora-commons-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >>> >> ------------------------------------------------------- >> >> Fachinformationszentrum Karlsruhe, Gesellschaft f?r >> wissenschaftlich-technische Information mbH. >> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB >> 101892. >> Gesch?ftsf?hrerin: Sabine Br?nger-Weilandt. >> Vorsitzender des Aufsichtsrats: MinR Hermann Riehl. >> >> >> > > > > > ------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------ > > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > > End of Fedora-commons-developers Digest, Vol 29, Issue 3 > ******************************************************** > ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
